On 10/25/06, Jacob Atzen <[EMAIL PROTECTED]> 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 > issues: > > - 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: Stables: X.Y.Z where Z is the bugfix / release part in case when pack a LOT of fixes between our release milestone. Unstable: Here we plan enhancements in another branch outside trunk, and label the releases: X.Y-builddate 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. > -- > Cheers, > - Jacob Atzen As Jacob said, this are also my 2 cents :-) Regards, -- Luis Lavena Multimedia systems - 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 is worthwhile. Vince Lombardi _______________________________________________ Mongrel-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/mongrel-users
