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. This will break everyone''s fantasy of having a 0.4 (it might be 0.948585 :-), but it''ll make it easier to track in the future. Additionally, I''ll start doing a svn tag for each pre-release and official release. Thanks a bunch. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://safari.oreilly.com/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
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. -- Cheers, - Jacob Atzen
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 > 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 AtzenAs 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
On Oct 25, 2006, at 10:38 AM, Jacob Atzen 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 kind of agree here. Why not just 0.3.4pre1, pre2, etc.?
On Wed, Oct 25, 2006 at 01:25:43PM -0700, Zed A. Shaw wrote:> On Wed, 25 Oct 2006 17:38:15 +0200 > Jacob Atzen <jacob at jacobatzen.dk> wrote: > > > On Tue, Oct 24, 2006 at 06:43:03PM -0700, Zed A. Shaw wrote: > > > > 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. > > > > The idea is that I want to get toward 1.0 for the final production > stable release. Many people have said that it''s mostly 1.0 quality > for them and it''d be an easier sell if I just labeled it that. Rather > than just pull a Subversion team manuever and call 0.3.3.245 the "1.0" > version on a magic release, I''m going to shorten the version number. > > So, in short a bugfix will just be 0.5. That''s it. When we hit 1.0 > the scheme will change.In that case my issues are without merit. Btw. I like the idea of numbering the pre-releases. It''s been kinda messy to tell which pre-release one was using previously. -- Thanks, - Jacob Atzen
On Wed, 25 Oct 2006 17:38:15 +0200 Jacob Atzen <jacob at jacobatzen.dk> wrote:> On Tue, Oct 24, 2006 at 06:43:03PM -0700, Zed A. Shaw wrote: > > 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. >The idea is that I want to get toward 1.0 for the final production stable release. Many people have said that it''s mostly 1.0 quality for them and it''d be an easier sell if I just labeled it that. Rather than just pull a Subversion team manuever and call 0.3.3.245 the "1.0" version on a magic release, I''m going to shorten the version number. So, in short a bugfix will just be 0.5. That''s it. When we hit 1.0 the scheme will change.> - 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. >Yep, that''s why I sent it out for comments. I think most folks just gem install, and they watch the list for my announcements, so the version number isn''t as important to them as seeing it increase and knowing what one is being installed. Also, I *never* release something that breaks everything and just rely on a version number to warn people. If I did say a 0.6 that broke everyone''s apps, it''d be announced for a long time before hand.> - 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.Thanks. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://safari.oreilly.com/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
On Wed, 25 Oct 2006 13:25:43 -0700 "Zed A. Shaw" <zedshaw at zedshaw.com> wrote:> On Wed, 25 Oct 2006 17:38:15 +0200 > Jacob Atzen <jacob at jacobatzen.dk> wrote: > > The idea is that I want to get toward 1.0 for the final production stable release. Many people have said that it''s mostly 1.0 quality for them and it''d be an easier sell if I just labeled it that. Rather than just pull a Subversion team manuever and call 0.3.3.245 the "1.0" version on a magic release, I''m going to shorten the version number.OOPS! Big correction on the above. It''d be "easier to sell" to their BOSS. I don''t sell Mongrel. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://safari.oreilly.com/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.
On Wed, 25 Oct 2006 22:19:46 +0200 Jacob Atzen <jacob at jacobatzen.dk> wrote:> On Wed, Oct 25, 2006 at 01:25:43PM -0700, Zed A. Shaw wrote: > > On Wed, 25 Oct 2006 17:38:15 +0200 > > Jacob Atzen <jacob at jacobatzen.dk> wrote: > Btw. I like the idea of numbering the pre-releases. It''s been kinda > messy to tell which pre-release one was using previously.This pre-release has been tagged, but not sure if it''s the Kosher way to do it for svn. I use svk so sometimes I''m shooting blind. It should be /tags/mongrel-0.3.14 Let me know if it''s not good. -- Zed A. Shaw, MUDCRAP-CE Master Black Belt Sifu http://www.zedshaw.com/ http://safari.oreilly.com/0321483502 -- The Mongrel Book http://mongrel.rubyforge.org/ http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.