| 2002 2003 2004 2005 2006 2007 2008 2009 <2010> 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 <2010> 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: Merges: 3.14.12 vs 3.15 |
| From: | Ralph Lange <[email protected]> |
| To: | "'Core-Talk'" <[email protected]> |
| Date: | Thu, 24 Jun 2010 17:59:41 -0400 |
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