Hi all,
In the past we had plans for minor releases [1], but invariably we end up
doing major ones, which also deliver the bug fixes.
The reason was the cost involved in doing a release. We have made some good
progress towards regression/integration test, which prompts me to revive
this.
What do
+1 in general. but yeah, not sure if we have resources to do this for every
major release.
On Mon, Dec 13, 2021 at 10:01 AM Vinoth Chandar wrote:
> Hi all,
>
> In the past we had plans for minor releases [1], but invariably we end up
> doing major ones, which also deliver the bug fixes.
>
> The
+1 on packing bug fixes (at best effort) to minor releases.
On Mon, Dec 13, 2021 at 12:06 PM Sivabalan wrote:
> +1 in general. but yeah, not sure if we have resources to do this for
> every major release.
>
> On Mon, Dec 13, 2021 at 10:01 AM Vinoth Chandar wrote:
>
>> Hi all,
>>
>> In the past
+1
I think it is really good for users
Em ter., 14 de dez. de 2021 22:01, Y Ethan Guo
escreveu:
> +1 on packing bug fixes (at best effort) to minor releases.
>
> On Mon, Dec 13, 2021 at 12:06 PM Sivabalan wrote:
>
> > +1 in general. but yeah, not sure if we have resources to do this for
> > ev
+1 to patch release as needed
Question: for a minor release, do we cherry-pick commits needed from master
or only land patches until the minor release is cut? The former can be
quite troublesome in resolving conflicts.
--
Best,
Raymond
On Tue, Dec 14, 2021 at 5:07 PM Rubens Rodrigues
wrote:
I guess we must do that for current rapid development and iteration. As for
the release 0.10.0, after the announcement of only a few days we have
received a bunch of bugs reported by the github issues: such as
- the empty meta file: https://github.com/apache/hudi/issues/4249
- and the timeline bas
+1
Agree that minor release mostly for bug fix purpose.
Best,
Vino
Danny Chan 于2021年12月15日周三 10:35写道：
> I guess we must do that for current rapid development and iteration. As for
> the release 0.10.0, after the announcement of only a few days we have
> received a bunch of bugs reported by the
+1
We could create new branches such as release-0.10 as the master branch for
0.10.0, 0.10.1 .etc version release, and when fixing bugs against the
master branch, the contributors/committers should also open a new PR
against the release-0.10 branch if needed. That would avoid cherry-picking
all bu
Hi all,
Thanks for chiming in with the feedback. Looks like there is broad support
for this.
Responding to few of the views below.
>With the rush in features without enough tests, I'm afraid the major
release version is never ready for production,
While I agree with you, don't want to be very id
Following up on having regular minor bug fix release, this is what I am
thinning.
major release every 2 months to 2.5 months and a minor bug fix release on
the following month of major release. If incase major release gets pushed,
we can skip having a 2nd minor release for now(due to resource
avail
Hi,
I would love for us to get into the cadence of a regular bug fix/minor
release, on top of the latest major version.
What do you think about a minor release every month?
Once there is a new major release, we will switch to issuing the next minor
release on top of it. i.e once 0.11.0 is out, the
> on top of the latest major version
Do you mean to include small features ? I would say that is not a good idea.
In general, we need the minor versions to converge the bugs introduced
by the major version, and 0.10.x is better because people know that
it is a quick follower after 0.10.0 to hand
12 matches
Mail list logo
