Hi,

Last time we were talking Lars (H.) raised the issue that we might need a
stable base while 0.96, and its successors are fully baked in for
production use. So, it seems that 0.94 branch releases will be a deployment
target for some time at least on some of the organizations for some time.
We have been backporting a lot of stuff already from trunk into 0.94, but I
want to discuss whether  we should establish an "official" policy of what
should be backported or not. We will definitely want bug fixes in,  but
what about new UI stuff, or integration tests, etc. If we can agree on
general guidelines at least, it will be then easier to decide on a
patch-by-patch basis. What do you guys think?

Enis

On Mon, Aug 20, 2012 at 11:16 AM, Enis Söztutar <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Last time we were talking Lars (H.) raised the issue that we might need a
> stable base while 0.96, and its successors are fully baked in for
> production use. So, it seems that 0.94 branch releases will be a deployment
> target for some time at least on some of the organizations for some time.
> We have been backporting a lot of stuff already from trunk into 0.94, but I
> want to discuss whether  we should establish an "official" policy of what
> should be backported or not. We will definitely want bug fixes in,  but
> what about new UI stuff, or integration tests, etc. If we can agree on
> general guidelines at least, it will be then easier to decide on a
> patch-by-patch basis. What do you guys think?
>

I'd think that 0.94 branch gets bug fixes only.  Anything else than
that gets confusing.

Do we want to have a 0.96 release that is not pb, branched from 0.94?
Into this 0.96 we'd backport non-pb stuff -- tests and 'safe'
features?

pb could then come out in a 0.98?

(Let me start a 0.96 thread.  I think we're close)

St.Ack

A reasonable policy could be:

- Bug fixes ported back two releases (so that's 0.94 and 0.92) if
applicable for the respective code base.

- Releases > 2 major versions back are "best effort". Assuming a committer
has an interest. I'm guessing Ram et. al. may have an interest in 0.90
branch for a while.

- No major user facing functionality changes: new UI, PB, etc.

- Build system changes and support like integration tests don't have an end
user impact so could be ok.
On Mon, Aug 20, 2012 at 12:18 PM, Stack <[EMAIL PROTECTED]> wrote:

> On Mon, Aug 20, 2012 at 11:16 AM, Enis Söztutar <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> > Last time we were talking Lars (H.) raised the issue that we might need a
> > stable base while 0.96, and its successors are fully baked in for
> > production use. So, it seems that 0.94 branch releases will be a
> deployment
> > target for some time at least on some of the organizations for some time.
> > We have been backporting a lot of stuff already from trunk into 0.94,
> but I
> > want to discuss whether  we should establish an "official" policy of what
> > should be backported or not. We will definitely want bug fixes in,  but
> > what about new UI stuff, or integration tests, etc. If we can agree on
> > general guidelines at least, it will be then easier to decide on a
> > patch-by-patch basis. What do you guys think?
> >
>
> I'd think that 0.94 branch gets bug fixes only.  Anything else than
> that gets confusing.
>
> Do we want to have a 0.96 release that is not pb, branched from 0.94?
> Into this 0.96 we'd backport non-pb stuff -- tests and 'safe'
> features?
>
> pb could then come out in a 0.98?
>
> (Let me start a 0.96 thread.  I think we're close)
>
> St.Ack
>

--
Best regards,

   - Andy

Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)

Since 0.94 will probably be a long lived version with many releases (thinking about 0.94.2 already),we should back port all changes that:
1. Do not break client/server compatibility (in both directions)

2. Do not break server/server compatibility
3. Do not rely on extensive refactoring that happened only in trunk
4. Are not just cosmetic
5. Do not just represent refactoring without any features added or bugs fixed
It includes bug fixes, performance improvements, even new features, etc.
But nothing that represents risk without an appropriate benefit.
#1 and #2 are hard rules, the rest is obviously subject to interpretation.

In terms of UI changes. We probably want to keep mere face lifts out, but include changes that provide extra information (new metrics, etc).
We definitely want any integrations tests back ported, unless the supporting changes to non-test code are extensive.
TL;DR: Back port unless there is a good reason not to; and use good judgment. :)  I'll be looking at most changes that go into 0.94.
Also, please do not assume that 0.96 is planned as an unstable release. That is not the case at all. It just might take a while to stabilize.
This is just off the top of my head, and as usual just my $0.02.
-- Lars

________________________________
 From: Enis Söztutar <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Monday, August 20, 2012 11:16 AM
Subject: Porting policy from 0.96+ to 0.94
 
Hi,

Last time we were talking Lars (H.) raised the issue that we might need a
stable base while 0.96, and its successors are fully baked in for
production use. So, it seems that 0.94 branch releases will be a deployment
target for some time at least on some of the organizations for some time.
We have been backporting a lot of stuff already from trunk into 0.94, but I
want to discuss whether  we should establish an "official" policy of what
should be backported or not. We will definitely want bug fixes in,  but
what about new UI stuff, or integration tests, etc. If we can agree on
general guidelines at least, it will be then easier to decide on a
patch-by-patch basis. What do you guys think?

Enis

Hmm... Reading the other responses... It seems there're more different opinions here.
Thanks for bringing this up Enis.

I can see a 0.96 branched from 0.94 without PB and some of the other 0.96 "singularity" features. (Although then the question arises: How would that be different from the 0.94.x?)
-- Lars

________________________________
 From: lars hofhansl <[EMAIL PROTECTED]>
To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Sent: Monday, August 20, 2012 1:56 PM
Subject: Re: Porting policy from 0.96+ to 0.94
 
Since 0.94 will probably be a long lived version with many releases (thinking about 0.94.2 already),we should back port all changes that:
1. Do not break client/server compatibility (in both directions)

2. Do not break server/server compatibility
3. Do not rely on extensive refactoring that happened only in trunk
4. Are not just cosmetic
5. Do not just represent refactoring without any features added or bugs fixed
It includes bug fixes, performance improvements, even new features, etc.
But nothing that represents risk without an appropriate benefit.
#1 and #2 are hard rules, the rest is obviously subject to interpretation.

In terms of UI changes. We probably want to keep mere face lifts out, but include changes that provide extra information (new metrics, etc).
We definitely want any integrations tests back ported, unless the supporting changes to non-test code are extensive.
TL;DR: Back port unless there is a good reason not to; and use good judgment. :)  I'll be looking at most changes that go into 0.94.
Also, please do not assume that 0.96 is planned as an unstable release. That is not the case at all. It just might take a while to stabilize.
This is just off the top of my head, and as usual just my $0.02.
-- Lars

________________________________
From: Enis Söztutar <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Sent: Monday, August 20, 2012 11:16 AM
Subject: Porting policy from 0.96+ to 0.94

Hi,

Last time we were talking Lars (H.) raised the issue that we might need a
stable base while 0.96, and its successors are fully baked in for
production use. So, it seems that 0.94 branch releases will be a deployment
target for some time at least on some of the organizations for some time.
We have been backporting a lot of stuff already from trunk into 0.94, but I
want to discuss whether  we should establish an "official" policy of what
should be backported or not. We will definitely want bug fixes in,  but
what about new UI stuff, or integration tests, etc. If we can agree on
general guidelines at least, it will be then easier to decide on a
patch-by-patch basis. What do you guys think?

Enis

If we do branch 0.96 from 0.94, then release current trunk as 0.98, it
might be confusing, no? Maybe a 0.95, if we wanna go that path?

Andrew and Lars's comments seem reasonable to me.

Enis

On Mon, Aug 20, 2012 at 4:18 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> Hmm... Reading the other responses... It seems there're more different
> opinions here.
> Thanks for bringing this up Enis.
>
> I can see a 0.96 branched from 0.94 without PB and some of the other 0.96
> "singularity" features. (Although then the question arises: How would that
> be different from the 0.94.x?)
>
>
> -- Lars
>
>
>
> ________________________________
>  From: lars hofhansl <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; "
> [EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Sent: Monday, August 20, 2012 1:56 PM
> Subject: Re: Porting policy from 0.96+ to 0.94
>
> Since 0.94 will probably be a long lived version with many releases
> (thinking about 0.94.2 already),we should back port all changes that:
> 1. Do not break client/server compatibility (in both directions)
>
> 2. Do not break server/server compatibility
> 3. Do not rely on extensive refactoring that happened only in trunk
> 4. Are not just cosmetic
> 5. Do not just represent refactoring without any features added or bugs
> fixed
>
>
> It includes bug fixes, performance improvements, even new features, etc.
> But nothing that represents risk without an appropriate benefit.
>
>
> #1 and #2 are hard rules, the rest is obviously subject to interpretation.
>
> In terms of UI changes. We probably want to keep mere face lifts out, but
> include changes that provide extra information (new metrics, etc).
> We definitely want any integrations tests back ported, unless the
> supporting changes to non-test code are extensive.
>
>
> TL;DR: Back port unless there is a good reason not to; and use good
> judgment. :)  I'll be looking at most changes that go into 0.94.
>
>
> Also, please do not assume that 0.96 is planned as an unstable release.
> That is not the case at all. It just might take a while to stabilize.
>
>
> This is just off the top of my head, and as usual just my $0.02.
>
>
> -- Lars
>
>
>
> ________________________________
> From: Enis Söztutar <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Monday, August 20, 2012 11:16 AM
> Subject: Porting policy from 0.96+ to 0.94
>
> Hi,
>
> Last time we were talking Lars (H.) raised the issue that we might need a
> stable base while 0.96, and its successors are fully baked in for
> production use. So, it seems that 0.94 branch releases will be a deployment
> target for some time at least on some of the organizations for some time.
> We have been backporting a lot of stuff already from trunk into 0.94, but I
> want to discuss whether  we should establish an "official" policy of what
> should be backported or not. We will definitely want bug fixes in,  but
> what about new UI stuff, or integration tests, etc. If we can agree on
> general guidelines at least, it will be then easier to decide on a
> patch-by-patch basis. What do you guys think?
>
> Enis
>

In my opinion, we should put more emphasis on tackling the blocking issues
of 0.96 so that 0.96 RC0 can be rolled some time this year.

Cheers

On Mon, Aug 20, 2012 at 4:24 PM, Enis Söztutar <[EMAIL PROTECTED]> wrote:

> If we do branch 0.96 from 0.94, then release current trunk as 0.98, it
> might be confusing, no? Maybe a 0.95, if we wanna go that path?
>
> Andrew and Lars's comments seem reasonable to me.
>
> Enis
>
> On Mon, Aug 20, 2012 at 4:18 PM, lars hofhansl <[EMAIL PROTECTED]>
> wrote:
>
> > Hmm... Reading the other responses... It seems there're more different
> > opinions here.
> > Thanks for bringing this up Enis.
> >
> > I can see a 0.96 branched from 0.94 without PB and some of the other 0.96
> > "singularity" features. (Although then the question arises: How would
> that
> > be different from the 0.94.x?)
> >
> >
> > -- Lars
> >
> >
> >
> > ________________________________
> >  From: lars hofhansl <[EMAIL PROTECTED]>
> > To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; "
> > [EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > Sent: Monday, August 20, 2012 1:56 PM
> > Subject: Re: Porting policy from 0.96+ to 0.94
> >
> > Since 0.94 will probably be a long lived version with many releases
> > (thinking about 0.94.2 already),we should back port all changes that:
> > 1. Do not break client/server compatibility (in both directions)
> >
> > 2. Do not break server/server compatibility
> > 3. Do not rely on extensive refactoring that happened only in trunk
> > 4. Are not just cosmetic
> > 5. Do not just represent refactoring without any features added or bugs
> > fixed
> >
> >
> > It includes bug fixes, performance improvements, even new features, etc.
> > But nothing that represents risk without an appropriate benefit.
> >
> >
> > #1 and #2 are hard rules, the rest is obviously subject to
> interpretation.
> >
> > In terms of UI changes. We probably want to keep mere face lifts out, but
> > include changes that provide extra information (new metrics, etc).
> > We definitely want any integrations tests back ported, unless the
> > supporting changes to non-test code are extensive.
> >
> >
> > TL;DR: Back port unless there is a good reason not to; and use good
> > judgment. :)  I'll be looking at most changes that go into 0.94.
> >
> >
> > Also, please do not assume that 0.96 is planned as an unstable release.
> > That is not the case at all. It just might take a while to stabilize.
> >
> >
> > This is just off the top of my head, and as usual just my $0.02.
> >
> >
> > -- Lars
> >
> >
> >
> > ________________________________
> > From: Enis Söztutar <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Sent: Monday, August 20, 2012 11:16 AM
> > Subject: Porting policy from 0.96+ to 0.94
> >
> > Hi,
> >
> > Last time we were talking Lars (H.) raised the issue that we might need a
> > stable base while 0.96, and its successors are fully baked in for
> > production use. So, it seems that 0.94 branch releases will be a
> deployment
> > target for some time at least on some of the organizations for some time.
> > We have been backporting a lot of stuff already from trunk into 0.94,
> but I
> > want to discuss whether  we should establish an "official" policy of what
> > should be backported or not. We will definitely want bug fixes in,  but
> > what about new UI stuff, or integration tests, etc. If we can agree on
> > general guidelines at least, it will be then easier to decide on a
> > patch-by-patch basis. What do you guys think?
> >
> > Enis
> >
>

I think a major consideration is that it is possible to do a rolling upgrade from 0.92 to 0.94 and the client/server protocol is unchanged
(or at least 100% compatible) between all versions of 0.92 and 0.94.

0.96 will require a more invasive upgrade, and is overall a riskier release.

So how about for 0.94: (1) bug fixes, (2) non invasive performance improvements, in addition to (3) non invasive, small new features if some committer/party shows interest?
There is an easy (without downtime) upgrade path from 0.92 to 0.94, so we *could* be less diligent about backporting to 0.92.

-- Lars
----- Original Message -----
From: Enis Söztutar <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]; lars hofhansl <[EMAIL PROTECTED]>
Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Sent: Monday, August 20, 2012 4:24 PM
Subject: Re: Porting policy from 0.96+ to 0.94

If we do branch 0.96 from 0.94, then release current trunk as 0.98, it
might be confusing, no? Maybe a 0.95, if we wanna go that path?

Andrew and Lars's comments seem reasonable to me.

Enis

On Mon, Aug 20, 2012 at 4:18 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:

> Hmm... Reading the other responses... It seems there're more different
> opinions here.
> Thanks for bringing this up Enis.
>
> I can see a 0.96 branched from 0.94 without PB and some of the other 0.96
> "singularity" features. (Although then the question arises: How would that
> be different from the 0.94.x?)
>
>
> -- Lars
>
>
>
> ________________________________
>  From: lars hofhansl <[EMAIL PROTECTED]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>; "
> [EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Sent: Monday, August 20, 2012 1:56 PM
> Subject: Re: Porting policy from 0.96+ to 0.94
>
> Since 0.94 will probably be a long lived version with many releases
> (thinking about 0.94.2 already),we should back port all changes that:
> 1. Do not break client/server compatibility (in both directions)
>
> 2. Do not break server/server compatibility
> 3. Do not rely on extensive refactoring that happened only in trunk
> 4. Are not just cosmetic
> 5. Do not just represent refactoring without any features added or bugs
> fixed
>
>
> It includes bug fixes, performance improvements, even new features, etc.
> But nothing that represents risk without an appropriate benefit.
>
>
> #1 and #2 are hard rules, the rest is obviously subject to interpretation.
>
> In terms of UI changes. We probably want to keep mere face lifts out, but
> include changes that provide extra information (new metrics, etc).
> We definitely want any integrations tests back ported, unless the
> supporting changes to non-test code are extensive.
>
>
> TL;DR: Back port unless there is a good reason not to; and use good
> judgment. :)  I'll be looking at most changes that go into 0.94.
>
>
> Also, please do not assume that 0.96 is planned as an unstable release.
> That is not the case at all. It just might take a while to stabilize.
>
>
> This is just off the top of my head, and as usual just my $0.02.
>
>
> -- Lars
>
>
>
> ________________________________
> From: Enis Söztutar <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Sent: Monday, August 20, 2012 11:16 AM
> Subject: Porting policy from 0.96+ to 0.94
>
> Hi,
>
> Last time we were talking Lars (H.) raised the issue that we might need a
> stable base while 0.96, and its successors are fully baked in for
> production use. So, it seems that 0.94 branch releases will be a deployment
> target for some time at least on some of the organizations for some time.
> We have been backporting a lot of stuff already from trunk into 0.94, but I
> want to discuss whether  we should establish an "official" policy of what
> should be backported or not. We will definitely want bug fixes in,  but
> what about new UI stuff, or integration tests, etc. If we can agree on
> general guidelines at least, it will be then easier to decide on a
> patch-by-patch basis. What do you guys think?

On Mon, Aug 20, 2012 at 6:23 PM, lars hofhansl <[EMAIL PROTECTED]> wrote:
> I think a major consideration is that it is possible to do a rolling upgrade from 0.92 to 0.94 and the client/server protocol is unchanged
> (or at least 100% compatible) between all versions of 0.92 and 0.94.

Indeed.

> 0.96 will require a more invasive upgrade, and is overall a riskier release.

Hopefully it won't prevent people from upgrading.

> So how about for 0.94: (1) bug fixes, (2) non invasive performance improvements, in addition to (3) non invasive, small new features if some committer/party shows interest?

That seems to be what we've already been doing, +1 from me.

> There is an easy (without downtime) upgrade path from 0.92 to 0.94, so we *could* be less diligent about backporting to 0.92.

Again I'm +1, we just went through that and not taking downtime was magic.

J-D