On Sat, Apr 19, 2008 at 12:24 PM, Malcolm Tredinnick
<[EMAIL PROTECTED]> wrote:
>
> > 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
Hello,
What is the meaning for the serial number in version_info? Is it some kind
of build number?
Sorry for the dumb question. :)
Anyway, I would be happy for having (major, minor, micro, release_level)
tuple as Django version info.
Regards,
Valts.
On Fri, Apr 18, 2008 at 9:52 PM, J. Cliff Dye
This all mostly makes sense. But there's one flaw (which I've described
twice below) that has caused problems on other projects and I suspect
will be a source of confusion with Django, too. A lot of our userbase
aren't the most experienced people in the world at extracting the
necessary informatio
On Fri, 2008-04-18 at 13:28 -0500, James Bennett wrote:
> On Fri, Apr 18, 2008 at 1:21 PM, Jacob Kaplan-Moss
> <[EMAIL PROTECTED]> wrote:
> > That said, I think I agree with Steve's idea of ripping of
> > sys.version_info: we've already stolen so much process from Python why
> > not add to this
On Fri, Apr 18, 2008 at 1:21 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
> That said, I think I agree with Steve's idea of ripping of
> sys.version_info: we've already stolen so much process from Python why
> not add to this list?
The main reason I didn't do that is simply that Python goe
As far as I'm concerned, this is firmly in the domain of release
manager duties. IOW, whatever James wants gets an automatic +1 from
me.
That said, I think I agree with Steve's idea of ripping of
sys.version_info: we've already stolen so much process from Python why
not add to this list?
Jacob
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 're
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. 'be
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
On Fri, Apr 18, 2008 at 11:41 AM, Andrew D. Ball <[EMAIL PROTECTED]> wrote:
> Look at what happens when I ask Django what version number it has (this is
> from release 0.96.1):
Honestly, for future releases I'd personally like to stick to a pattern of
(major, minor, modifier)
So if we release
>From my blog post on this topic [ http://tinyurl.com/4fw9u6 ]:
Look at what happens when I ask Django what version number it has (this is
from release 0.96.1):
==
[EMAIL PROTECTED]:~$ python
Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubunt
11 matches
Mail list logo
