Emmanuel, This 1.5, 2.5, 3.5 etc feature introduction branches along with 1.0, 2.0, 3.0 for the stable bug fix branch is alright by me. Really to me the goal is to be able to have a branch where only new features are introduced and another where we just make bug fixes. New features can destabilize the server even though it has not yet. This scheme is just the same to me as using the odd/even scheme. Perhaps the odd/even scheme is a tiny bit more preferrable because people can relate to the Linux way to understand this. However I really like this 1.5 schema because the message is a bit clearer that we're transitioning from one stable bug fix branch to the next.
Effectively both are the same for me. However let me clarify why I personally like to have a feature release branch and a separate bug fix branch. 1. New features may destabilize the server 2. New features also may change interfaces 3. Feature branches buffer users from drastic compatibility changes like in the partition format 4. Also it's easier to track the generational differences between stable releases which simplifies the maintenance, and the documentation. So this is why a feature release branch is a good idea for me. However there are some disadvantages as well. 1. Users perceive the feature release branches as buggy when they are not necessarily unstable 2. Users have to wait longer for stable releases of the features they want and may not opt to use releases from the unstable branch There may be more but perhaps others can add to both these lists with their own pros and cons. Alex On 5/7/07, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:
Alan D. Cabrera a écrit : > > On May 5, 2007, at 5:18 AM, Emmanuel Lecharny wrote: > >> Ok, I agree with a lot of Chris points. We have to find an easier >> way to enumerate versions, and the odd/even scheme does not fit me a >> lot, because the semantic is not very clear. However, I also think >> that Alex is right when it comes to have stable/unstable revisions >> (keep in mind that unstable != buggy, but unstable == experimental) >> >> We have had a convo with Alex this morning while we were moving to >> the airport : what about using the X for each 'stable version ? >> Like : 1.0.z, 2.0.z, 3.0.z... are stable versions (X.0.z will >> *always* be stable versions) >> >> Now, for experimental/unstable versions, I suggest to use the Y part : >> >> 1.5.z, 2.5.z, ... X.5.z will be experimental versions >> >> The idea behind is to express the fact that we are just in the >> middle of two stable versions. We won't have 1.6.0, but a 2.0.0. If >> we have to add a new feature, or fix a bug, then we switch to the >> next Z number : from 1.5.0 to 1.5.1, or from 2.0.0 to 2.0.1 >> >> To make it clear, we will use the X.Y.Z scheme where : >> X : major version >> Y : if 0, then the version is stable, and feature completed. If 5, >> then this is an intermediate version >> Z : used for bug fixes if Y=0, or for new features or bug fixes if Y=5. >> >> 1.5.2 => new features has been added to 1.5.1 >> 2.0.3 => stable version 2, with third delivered set of bug fixes. >> >> wdyt ? > > > > This all sounds a bit abstract to me. Can you provide some concrete > uses cases that provide compelling reasons to have a stable/unstable > releases occurring at the same time? Thanks! The key word is 'release'. We have had many discussion about what we should call a release, and if we should have 'unstable' released at all... Tags may be enough. But on the other side, Alex thinks that the stable/unstable scheme (à la Linux) is a good thing. This is what we are trying to address, so this mail. Thanks Alan ! > > > Regards, > Alan > >
