As you said, it's a bikeshed argument, so I'm not going to push hard on this, but I do want to put one thing out for discussion. There is some value in making versions increase in sort order, so you can do "if django.VERSION > target:". If 'final' were changed to 'release', this would work. 'beta' < 'rc' < 'release' < 'svn'.
Just a thought. And to throw a wrench into everything, including my own thought, what would branch versions look like in your scheme? Cheers, Cliff On Fri, 2008-04-18 at 12:46 -0500, James Bennett wrote: > And because lately we've been doing various specification-type things, > I'd like to propose (with release manager hat firmly planted on my > head) that going forward we do things in the following fashion. > > > Format of ``django.VERSION`` > ============================ > > ``django.VERSION`` is a 3-tuple, of the form:: > > (major-version, minor-version, modifier) > > > Packaged releases > ================= > > In a packaged release, the elements of the ``django.VERSION`` tuple > are: > > 1. The major version tree from which the release is packaged. > > 2. The minor version the package represents. > > 3. A modifier indicating the release status of the package. > > The modifier may take any one of the following four forms: > > 1. 'beta<n>'; this is a beta leading up to a final release, and '<n>' > represents the number of the beta release; the first beta for 1.0, > for example, would be (1, 0, 'beta1'), the second beta for 1.0 > would be (1, 0, 'beta2'), etc. > > 2. 'rc<n>'; this is a release candidate leading up to a final release, > and '<n>' represents the number of the release candidate; the first > release candidate for 1.0, for example, would be (1, 0, 'rc1'), the > second release candidate for 1.0 would be (1, 0, 'rc2'), etc. > > 3. 'final'; this is the packaged release of a specific version of > Django, and represents a stable, tested version to which the Django > project commits support per the support/security policy. Django 1.0 > would, for example, be (1, 0, 'final'), Django 1.1 would be (1, 1, > 'final'), etc. > > 4. 'p<n>'; this is a bugfix and/or security release for a prior > version of Django, released in accordance with the support/security > policy. The first such release for Django 1.0 would be (1, 0, > 'p1'), the second such release for Django 1.0 would be (1, 0, > 'p2'), etc. > > > SVN checkouts > ============= > > For an SVN checkout, the elements of the ``django.VERSION`` tuple are: > > 1. The most recent major version released at the time of the specific > SVN revision being checked out. > > 2. The most recent minor version released at the time of the specific > SVN revision being checked out. > > 3. The modifier 'svn<n>', indicating an SVN checkout, where '<n>' is > the revision of the checkout from the repository. > > So, for example, if you do an SVN checkout of revision 31337 and, at > the time of that revision, the most recent major version was 3 and the > most recent minor version was 14, then VERSION in your checkout will > be:: > > (3, 14, 'svn31337') > > > Why this is a good thing > ======================== > > How to do the version tuple is mostly a bikeshed argument. Ultimately, > three things matter in deciding how to handle it: > > 1. The BDFLs/core dev team are OK with it. > > 2. The system used is consistent. > > 3. The system used is easy to parse into human-readable formats. > > The above system meets (2) and (3) -- it offers a version tuple in a > consistent format, and one which is easy to turn into a human-readable > string like "Django 3.2", "Django 1.4-beta3" or "Django > 2.18-svn28183". > > The only question is whether it meets (1). Thoughts? > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
