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
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
If 1.0 is soon then I can handle the wait. It's just a PITA right now
because .96 is so old, and trunk is so vast. Many people use trunk,
but don't update continuously (as it is trunk after all). So you end
up with a bunch of people in the midst of "why doesn't this work", or
"why is it
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
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
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
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.
I am in agreement on waiting to release a 1.0 beta, however keeping
track of tickets for the milestones of merging qs-rf and nfa(and those
are deffinately milestones) would be very handy, right now in order to
follow those one needs to play around with keywords(for example qs-rf
tickets are
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,
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
On Wed, Apr 16, 2008 at 6:47 PM, David Cramer <[EMAIL PROTECTED]> wrote:
> Can we start setting some milestones so SVN stops being SVN :)
>
> E.g. a .97 release, or .96.2 or something.
My preference would be to finish up newforms-admin and
queryset-refactor, then release a 1.0 beta. Given that
>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
On Fri, 2008-04-18 at 11:47 -0400, Jay Wineinger wrote:
> I realize that you can do it with initial. I was asking (unclearly,
> evidently) if there would be any value to changing django to work in
> that way.
One way to do any given thing is enough. Your method isn't really
anysaving in
I realize that you can do it with initial. I was asking (unclearly,
evidently) if there would be any value to changing django to work in
that way.
Jay
[EMAIL PROTECTED] wrote:
> This question should be directed to django-users, this group is for
> django development, not support.
>
>
>
>
I posed this question on IRC and was told to direct it here because it
might be "interesting".
I created a ModelForm with additional fields which aren't present on
the model. Now, I want to use this form to edit an instance of the
model, but there doesn't seem to be a way set the additional
This question should be directed to django-users, this group is for
django development, not support.
class MyModel(models.Model):
field_a =
field_b =
class MyModelForm(forms.ModelForm):
field_c = ...
class Meta:
model = MyModel
mymodel = MyModel()
17 matches
Mail list logo
