J. Cliff Dyer wrote:
> 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). Thoug
Without wishing to turn this into a long-drawn-out discussion, why be
willfully different from Python itself? From 2.0 on there's been a
standard of sorts in sys.version_info:
"""*version_info*
A tuple containing the five components of the version number: major,
minor, micro, releaselevel, and serial. All values except
releaselevel are integers; the release level is |'alpha'|, |'beta'|,
|'candidate'|, or |'final'|. The |version_info| value corresponding
to the Python version 2.0 is |(2, 0, 0, 'final', 0)|. New in version
2.0.
"""
No biggy, but if everyone stuck to the same versioning rules it would be
worth building in core functionality to handle the version data, in so
far as it needs handling.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
