correct, branch-1.2 was the stable release line prior to 1.4 becoming
it in August.
at the time I said I'd keep making monthly 1.2.z releases for ~6 months:
https://s.apache.org/EYkB
I wanted to give folks who heed our "this is the stable line" advice a
cushion for planning migration once we
We could do that. Or we could simply renumber branch-1 to 1.6.x at that
time, e.g. 1.5.whatever-SNAPSHOT -> 1.6.0-SNAPSHOT. Every release has a tag
in rel/. It is possible at any time to check out from a release tag and
make a branch for an additional patch release for an old minor line. If we
+1. But branch-1.2 is not EOL now?
张铎(Duo Zhang) 于2018年12月8日周六 上午9:28写道:
> +1.
>
> Andrew Purtell 于2018年12月8日周六 上午5:45写道:
>
> > I'm good with doing one more 1.3 release. It would be my pleasure to
> offer
> > that service to the community. I like RM-ing.
> >
> >
> > On Fri, Dec 7, 2018 at
Yeah, for branch-1 it is no longer a development branch. Every change is
going to be maintenance related. No, I don't expect 1.5 to be the last
minor release line for 1.x. Maybe? Maybe not. In theory we could treat
branch-2 the same. Master is the only development branch. That is not my
proposal,
So the idea is that, if we have a newer major release line, we can release
the previous major releases directly from the 'developing' branch?
I think for branch-1 it is fine, as we are not likely to backport any big
new feature to 1.x any more. And does this mean that 1.5 is the last minor
+1.
Andrew Purtell 于2018年12月8日周六 上午5:45写道:
> I'm good with doing one more 1.3 release. It would be my pleasure to offer
> that service to the community. I like RM-ing.
>
>
> On Fri, Dec 7, 2018 at 12:29 PM Stack wrote:
>
> > +1
> >
> > (Pity you have to make a release to EOL it).
> >
> > S
> >
I'm good with doing one more 1.3 release. It would be my pleasure to offer
that service to the community. I like RM-ing.
On Fri, Dec 7, 2018 at 12:29 PM Stack wrote:
> +1
>
> (Pity you have to make a release to EOL it).
>
> S
>
> On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell
> wrote:
>
> >
+1
(Pity you have to make a release to EOL it).
S
On Fri, Dec 7, 2018 at 11:25 AM Andrew Purtell wrote:
> We haven't had a release from branch-1.3 for a long time and do not appear
> to have an active RM for it. Unless a RM for 1.3 steps forward and promises
> to make a release in the very
On Fri, Dec 7, 2018 at 11:36 AM Andrew Purtell wrote:
> Please be advised I plan to RM the next minor release from branch-1, 1.5.0,
> in January of 2019. Once this is done we can continue making maintenance
> releases from branch-1.4 as needed but expect that not to be necessary
> after a couple
big +1 from me.
On Fri, Dec 7, 2018 at 1:25 PM Andrew Purtell wrote:
>
> We haven't had a release from branch-1.3 for a long time and do not appear
> to have an active RM for it. Unless a RM for 1.3 steps forward and promises
> to make a release in the very near future, I propose we make one more
yes please this would be great!
I have a DISCUSS thread I've been drafting about doing the same thing
for branch-2 releases. I think in general we need to get back in the
habit of only making maintenance releases when someone steps forward
with a specific need.
I plan to keep making branch-1.2
Please be advised I plan to RM the next minor release from branch-1, 1.5.0,
in January of 2019. Once this is done we can continue making maintenance
releases from branch-1.4 as needed but expect that not to be necessary
after a couple of months (or perhaps even immediately).
I see no need to make
We haven't had a release from branch-1.3 for a long time and do not appear
to have an active RM for it. Unless a RM for 1.3 steps forward and promises
to make a release in the very near future, I propose we make one more
release of 1.3, from the head of branch-1.3, and then retire the branch. If
13 matches
Mail list logo