My main concern with all of the implied meaning in the release numbers is that the users will not pay attention to it, and eventually get irritated with it when they have an issue with a new feature and we tell them that they probably shouldn't play with their shiny new toy in production.
Last night it occured to me that maybe we have all overlooked an obvious solution that could make everyone happy. With the unstable feature releases we are basically talking about a very formal beta testing phase. So maybe we should call these releases beta releases, but without any special meaning embedded in the numbers. So after a stable release of 1.6, why don't we do the typical release branch for bugfixe releases like 1.6.1, work off of the trunk for the next major release and do releases from trunk as 1.7 beta 1, 1.7 beta 2, etc. until things are stable. Or at least something along these lines. I think this will make much more sense to the users and allows the Directory project to introduce new features in beta releases without worry of tripping up any bleeding edge users using beta releases.
There are a couple of small drawbacks. Even though I see other projects doing it, we shouldn't release beta builds on the main maven repo, although I am not sure this is a hard rule, I think it is a general practice not to do it. However this leads back to the main argument that the special unstable build numbers are misleading when deployed to maven repos because the user may not realize what the build number means and could use it in a production app.
I hate to spend so much time on this type of subject, but I just want to make sure that the users see things clearly and that we don't impose any special rules on them with released versions. The beta solution may not be the prettiest, but there is a lot of precedent with other projects and vendor products out there and at least this way the users know exactly what they are getting when they download and install ;-) So consider this just another suggestion...
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.
AlexOn 5/7/07, Emmanuel Lecharny < email@example.com> 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 !