[Mongrel] [ANN] Change In Versioning Policy
luislavena at gmail.com
Wed Oct 25 12:22:31 EDT 2006
On 10/25/06, Jacob Atzen <jacob at jacobatzen.dk> wrote:
> On Tue, Oct 24, 2006 at 06:43:03PM -0700, Zed A. Shaw wrote:
> > I'm going to make a change to how Mongrel is versioned to help out folks packaging it and tracking it as a pre-release. Previously I just did whatever was simplest, but now I'm going to do a slightly different approach. This is open for comment and suggestions.
> > Here's the new rules:
> > 1) There are only official and pre-releases. This doesn't change.
> > 2) The version number is only 3 digits: X.Y.Z
> > 3) The pre-releases will change the Z number for each release.
> > 4) The official releases will change the Y number and reset the Z number to 0.
> Maybe I don't understand what is meant by pre-release, but I have a few
> - If a bugfix is needed for 0.4.0 what would it be called? 0.4.1 does
> not seem to be a possibility as it may already have been released as
> pre-release to 0.5.
> - Users might get confused about this scheme, as it contradicts the
> usual scheme were the Z value indicates a minor update, say 0.3.Z+1 is a
> minor update of 0.3.Z. With the proposed scheme I assume 0.3.1 could
> add features or break compability with 0.3.0.
> - I am not convinced that the various packaging systems out there will
> be really happy about this scheme, though this is just a feeling.
> That's just my 2 cents, hope you can use it.
Jacob has a point here.
The X.Y.Z scheme of versioning for most software is:
Mayor, Minor, bugfix/build
When you add features, but not a rewrite or complete redesign, you
increment the minor version.
As different example, GNOME mark all their unstable releases with odd
numbers (2.17) and the stables with even (2.16)
For any of the releases, stable or unstable (pre-releases) they do
bugfixing (using the X.Y.Z scheme).
In contrast, Subversion do bug fixing with the Z, and use the Minor to
maintain backward compatibility between releases...
A 1.3.x client could connect 1.3.x servers or 1.4.x, but will not take
advantage of the new functionality.
If versions range are 1.3-1.4 everything will be good, but no
guarantees of support between 1.1.x server (or 1.2.x) with a 1.4.x
client (or vice versa).
I often name my releases:
X.Y.Z where Z is the bugfix / release part in case when pack a LOT of
fixes between our release milestone.
Here we plan enhancements in another branch outside trunk, and label
So if last stable was 0.3.2 our pre-release/beta is 0.4-20061025.
Anyway, we don't package prereleases every day, so is easy to
determine which pre-release we are talking about.
Also, in this case, as Zed did, will leave all the pre-releases
outside rubyforge to reduce clutter during gems updates.
> - Jacob Atzen
As Jacob said, this are also my 2 cents :-)
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
More information about the Mongrel-users