Re: Merges: 3.14.12 vs 3.15

[Ralph Lange <Ralph.Lange@bessy.de>]

On Thu 24 Jun 2010 17:36:56 Andrew Johnson wrote:
> On Thursday 24 June 2010 15:16:25 Jeff Hill wrote:
>   
> > Maybe the solution is to have three independent release series: maybe we
> > should have the stable production release, the near term features release,
> > and the evolution release. With that approach we can have an independent
> > release series on all three versions simultaneously. With this approach it
> > needs to be very clear to everyone involved where we are headed. That is,
> > it needs to be very clear that day-to-day support of the production release
> > will after some longer period of time go away, the near term release will
> > be eventually declared to be the production release, and the evolution
> > release will eventually become the near-term feature release. What do you
> > think?
> >     
> The way I see it, 3.14.11+patches is our stable production release, the 3.14 
> series is our near-term features release, and the other branches in Bazaar 
> demonstrate the directions we might go in.  Using a DVCS and publishing lots 
> of branches allows us to to avoid having to choose a single direction for 
> evolution before the development on each is finished; I see that as much more 
> Darwinian (and less risky) than the old CVS approach of having a single branch 
> for future evolution.
>   
After a discussion with Michael (also see his mail) it is becoming clear 
that we might have to reconsider our release policies and schedules. As 
you pointed out, the DVCS feature branches allow easier cherrypicking 
for the main direction; they would also make backporting single features 
to older releases easier.
We should allow a faster integration of "heavy" new features (so that 
switching to cmake does not take 8 years), so maybe we need to be 
stepping up the minor number more frequent. (Maybe that is getting 
easier as we pass pi, but automated tests are crucial for any release 
model to work.)
In the end, the conflict is alway the same: We need to provide stable 
versions, and must not break production installations. But we also need 
people to be able to use new features, else those will never get mature 
enough to go into the stable version.
> As Ralph pointed out, your work is not yet suitable for merging, and you 
> haven't posted a merge proposal for it (he is wrong about the code visibility 
> though, your changes are on the cvs-trunk branch).
Andrew is right, I'm sorry.
I did not consider the cvs-trunk branch an active development area, so I 
completely ignored it.
Ralph