You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by Andrew Purtell <ap...@apache.org> on 2014/08/21 19:07:04 UTC
[VOTE] Fork branch '4.0' into branches '4.0' and '4.1'
The latest code on branch 4.0 builds as version 4.1.0.
I propose the following series of actions:
- Create a new branch 4.1 at the revision where the version in the POM was
updated to 4.1.0.
- Reset the branch 4.0 head to the version prior, with a force push
Let's use lazy consensus (
http://www.apache.org/foundation/voting.html#LazyConsensus) and run this
vote for 72 hours. If nobody objects I will take the above actions Monday
8/24.
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: [VOTE] Fork branch '4.0' into branches '4.0' and '4.1'
Posted by Jesse Yates <je...@gmail.com>.
IMO having releases on a 4.0 branch that do not start with 4.0 is very
confusing.
By moving to the 4.1 branch we are essentially saying the 4.0.x line is
essentially only there for emergency bug fixes. With your logic above, even
if the person found a bug on their 4.0.x line they would be able to upgrade
to the latest 4.X branch seamlessly.
4.1 should not be incompatible with 4.0 - by the semantic naming Phoenix is
currently using (and your example above). I don't really see any reason why
we couldn't change it.
This is really more of a semantic change, rather than any more actual work.
However, by doing this now we set ourselves up for having multiple branches
later that could be managed by different RMs if people have issues.
If someone else wants to maintain the 4.0 branch, then I think they should
be able to. Apache and Phoenix are volunteer efforts, so people can choose
to stop working on things when they want or to pick up things that others
have left behind.
-------------------
Jesse Yates
@jesse_yates
jyates.github.com
On Thu, Aug 21, 2014 at 10:34 AM, James Taylor <ja...@apache.org>
wrote:
> IMHO, I don't think we have the bandwidth to maintain any more
> branches. I'm also not sure this fits the criteria for a lazy
> consensus vote.
>
> The original intent of the 4.0 branch was meant to host all 4.x
> releases. In general releases are compatible in the following manner:
> - a minor release must be deployed first on the server and then at any
> point later on the client. It will require a rolling restart, but no
> downtime.
> - a patch release may be deployed on the client and server in either
> order. If the patch requires the server jar to be deployed (which
> would likely be most of the time), it will require a rolling restart
> and no downtime will be required.
> - a major release may require downtime, as it may require the client
> and server side to both be deployed together.
>
> Given this, the model was that folks would upgrade to the latest
> 3.0/4.0 release if they need a particular fix. For example, if someone
> is on 4.0.0 and a bug gets fixed down the road in 4.2.5, they should
> be able to upgrade as above relatively seamlessly.
>
> This CDH incompatibility is different. I think we should brainstorm on
> that one in a different thread.
>
> Thanks,
> James
>
>
> On Thu, Aug 21, 2014 at 10:08 AM, Andrew Purtell <ap...@apache.org>
> wrote:
> > Monday 8/25 :-)
> >
> >
> > On Thu, Aug 21, 2014 at 10:07 AM, Andrew Purtell <ap...@apache.org>
> > wrote:
> >
> >> The latest code on branch 4.0 builds as version 4.1.0.
> >>
> >> I propose the following series of actions:
> >>
> >> - Create a new branch 4.1 at the revision where the version in the POM
> was
> >> updated to 4.1.0.
> >>
> >> - Reset the branch 4.0 head to the version prior, with a force push
> >>
> >> Let's use lazy consensus (
> >> http://www.apache.org/foundation/voting.html#LazyConsensus) and run
> this
> >> vote for 72 hours. If nobody objects I will take the above actions
> Monday
> >> 8/24.
> >>
> >> --
> >> Best regards,
> >>
> >> - Andy
> >>
> >> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> >> (via Tom White)
> >>
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
>
Re: [VOTE] Fork branch '4.0' into branches '4.0' and '4.1'
Posted by James Taylor <ja...@apache.org>.
@Andrew - I wish we had used those names in the first place, as I
agree it would avoid the confusion you mentioned.
@Jesse - you make a good point - this is a volunteer effort. Just
speaking for myself, I don't have the bandwidth to commit any changes,
do any support, provide any documentation, coordinate any releases, do
regression testing, advertise/market, or do any emergency bug fixes to
any more branches.
Either of these changes have downstream effects: updating jenkins
builds, changing documentation (or even documenting existing
process/branching and release strategy as in the email). If someone
wants to volunteer and make these changes (post 3.1/4.1 release,
please), I'm +1.
Thanks,
James
On Thu, Aug 21, 2014 at 11:05 AM, Andrew Purtell <ap...@apache.org> wrote:
> Ok, let's declare this vote as failed.
>
>
> On Thu, Aug 21, 2014 at 10:53 AM, Mujtaba Chohan <mu...@apache.org> wrote:
>
>> +1. 4.0 named as 4.x or 4, 3.0 named as 3.x or 3
>>
>>
>> On Thu, Aug 21, 2014 at 10:48 AM, Andrew Purtell <ap...@apache.org>
>> wrote:
>>
>> > On Thu, Aug 21, 2014 at 10:34 AM, James Taylor <ja...@apache.org>
>> > wrote:
>> >
>> > > The original intent of the 4.0 branch was meant to host all 4.x
>> > > releases. In general releases are compatible in the following manner:
>> > > - a minor release must be deployed first on the server and then at any
>> > > point later on the client. It will require a rolling restart, but no
>> > > downtime.
>> > > - a patch release may be deployed on the client and server in either
>> > > order. If the patch requires the server jar to be deployed (which
>> > > would likely be most of the time), it will require a rolling restart
>> > > and no downtime will be required.
>> > > - a major release may require downtime, as it may require the client
>> > > and server side to both be deployed together.
>> > >
>> >
>> > If you like I could make an alternate proposal to rename the branches to
>> > branch-4 (and branch-3), then.
>> >
>> > Having a branch named '4.0' that builds releases 4.1.x is bound to
>> confuse,
>> > IMHO.
>> >
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > - Andy
>> >
>> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> > (via Tom White)
>> >
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
Re: [VOTE] Fork branch '4.0' into branches '4.0' and '4.1'
Posted by Andrew Purtell <ap...@apache.org>.
Ok, let's declare this vote as failed.
On Thu, Aug 21, 2014 at 10:53 AM, Mujtaba Chohan <mu...@apache.org> wrote:
> +1. 4.0 named as 4.x or 4, 3.0 named as 3.x or 3
>
>
> On Thu, Aug 21, 2014 at 10:48 AM, Andrew Purtell <ap...@apache.org>
> wrote:
>
> > On Thu, Aug 21, 2014 at 10:34 AM, James Taylor <ja...@apache.org>
> > wrote:
> >
> > > The original intent of the 4.0 branch was meant to host all 4.x
> > > releases. In general releases are compatible in the following manner:
> > > - a minor release must be deployed first on the server and then at any
> > > point later on the client. It will require a rolling restart, but no
> > > downtime.
> > > - a patch release may be deployed on the client and server in either
> > > order. If the patch requires the server jar to be deployed (which
> > > would likely be most of the time), it will require a rolling restart
> > > and no downtime will be required.
> > > - a major release may require downtime, as it may require the client
> > > and server side to both be deployed together.
> > >
> >
> > If you like I could make an alternate proposal to rename the branches to
> > branch-4 (and branch-3), then.
> >
> > Having a branch named '4.0' that builds releases 4.1.x is bound to
> confuse,
> > IMHO.
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: [VOTE] Fork branch '4.0' into branches '4.0' and '4.1'
Posted by Mujtaba Chohan <mu...@apache.org>.
+1. 4.0 named as 4.x or 4, 3.0 named as 3.x or 3
On Thu, Aug 21, 2014 at 10:48 AM, Andrew Purtell <ap...@apache.org>
wrote:
> On Thu, Aug 21, 2014 at 10:34 AM, James Taylor <ja...@apache.org>
> wrote:
>
> > The original intent of the 4.0 branch was meant to host all 4.x
> > releases. In general releases are compatible in the following manner:
> > - a minor release must be deployed first on the server and then at any
> > point later on the client. It will require a rolling restart, but no
> > downtime.
> > - a patch release may be deployed on the client and server in either
> > order. If the patch requires the server jar to be deployed (which
> > would likely be most of the time), it will require a rolling restart
> > and no downtime will be required.
> > - a major release may require downtime, as it may require the client
> > and server side to both be deployed together.
> >
>
> If you like I could make an alternate proposal to rename the branches to
> branch-4 (and branch-3), then.
>
> Having a branch named '4.0' that builds releases 4.1.x is bound to confuse,
> IMHO.
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: [VOTE] Fork branch '4.0' into branches '4.0' and '4.1'
Posted by Andrew Purtell <ap...@apache.org>.
On Thu, Aug 21, 2014 at 10:34 AM, James Taylor <ja...@apache.org>
wrote:
> The original intent of the 4.0 branch was meant to host all 4.x
> releases. In general releases are compatible in the following manner:
> - a minor release must be deployed first on the server and then at any
> point later on the client. It will require a rolling restart, but no
> downtime.
> - a patch release may be deployed on the client and server in either
> order. If the patch requires the server jar to be deployed (which
> would likely be most of the time), it will require a rolling restart
> and no downtime will be required.
> - a major release may require downtime, as it may require the client
> and server side to both be deployed together.
>
If you like I could make an alternate proposal to rename the branches to
branch-4 (and branch-3), then.
Having a branch named '4.0' that builds releases 4.1.x is bound to confuse,
IMHO.
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: [VOTE] Fork branch '4.0' into branches '4.0' and '4.1'
Posted by James Taylor <ja...@apache.org>.
IMHO, I don't think we have the bandwidth to maintain any more
branches. I'm also not sure this fits the criteria for a lazy
consensus vote.
The original intent of the 4.0 branch was meant to host all 4.x
releases. In general releases are compatible in the following manner:
- a minor release must be deployed first on the server and then at any
point later on the client. It will require a rolling restart, but no
downtime.
- a patch release may be deployed on the client and server in either
order. If the patch requires the server jar to be deployed (which
would likely be most of the time), it will require a rolling restart
and no downtime will be required.
- a major release may require downtime, as it may require the client
and server side to both be deployed together.
Given this, the model was that folks would upgrade to the latest
3.0/4.0 release if they need a particular fix. For example, if someone
is on 4.0.0 and a bug gets fixed down the road in 4.2.5, they should
be able to upgrade as above relatively seamlessly.
This CDH incompatibility is different. I think we should brainstorm on
that one in a different thread.
Thanks,
James
On Thu, Aug 21, 2014 at 10:08 AM, Andrew Purtell <ap...@apache.org> wrote:
> Monday 8/25 :-)
>
>
> On Thu, Aug 21, 2014 at 10:07 AM, Andrew Purtell <ap...@apache.org>
> wrote:
>
>> The latest code on branch 4.0 builds as version 4.1.0.
>>
>> I propose the following series of actions:
>>
>> - Create a new branch 4.1 at the revision where the version in the POM was
>> updated to 4.1.0.
>>
>> - Reset the branch 4.0 head to the version prior, with a force push
>>
>> Let's use lazy consensus (
>> http://www.apache.org/foundation/voting.html#LazyConsensus) and run this
>> vote for 72 hours. If nobody objects I will take the above actions Monday
>> 8/24.
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
Re: [VOTE] Fork branch '4.0' into branches '4.0' and '4.1'
Posted by Andrew Purtell <ap...@apache.org>.
Monday 8/25 :-)
On Thu, Aug 21, 2014 at 10:07 AM, Andrew Purtell <ap...@apache.org>
wrote:
> The latest code on branch 4.0 builds as version 4.1.0.
>
> I propose the following series of actions:
>
> - Create a new branch 4.1 at the revision where the version in the POM was
> updated to 4.1.0.
>
> - Reset the branch 4.0 head to the version prior, with a force push
>
> Let's use lazy consensus (
> http://www.apache.org/foundation/voting.html#LazyConsensus) and run this
> vote for 72 hours. If nobody objects I will take the above actions Monday
> 8/24.
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)