ANN: Upcoming backwards-incompatible changes to Django development version

19 views
Skip to first unread message

Adrian Holovaty

unread,
Apr 6, 2007, 10:01:18 AM4/6/07
to django-...@googlegroups.com, django...@googlegroups.com
Hi all,

For a long time, we've recommended that people use the Django
development version instead of the latest Django release, as we try
hard to keep the development version stable. We're loosening that
policy, temporarily, for the immediate future, in order to make a
number of backwards-incompatible changes to the development version.

Examples of some of these changes are:

* Removing the "auto_now" and "auto_now_add" options in Django models.

* Finishing and merging the "newforms-admin" branch, which changes the
way admin options are specified (and gives you a lot more
flexibility):
http://code.djangoproject.com/wiki/NewformsAdminBranch

* Removing the LazyDate shortcut.

* Renaming django.contrib.localflavor.usa to django.contrib.localflavor.us.

The biggest change is probably the newforms-admin functionality.

So, the moral of this e-mail is that if you use the Django development
version in production settings (as many people, including I, do), take
a look at the "Backwards-incompatible changes" wiki page before
updating your Django code to make sure your code won't break. Here's
that page:

http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges

This is, we hope, the final run of backwards-incompatible changes
before version 1.0, at which point we'll be committed to
compatibility.

If you'd like to discuss these changes, feel free to post a message to
the django-developers mailing list:

http://groups.google.com/group/django-developers

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

Henrik Lied

unread,
Apr 6, 2007, 1:52:20 PM4/6/07
to Django users
> Examples of some of these changes are:
>
> * Removing the "auto_now" and "auto_now_add" options in Django models.
>
Is this removed without a substitute?


> * Removing the LazyDate shortcut.
>

Again, is this removed without a substitute?

anders conbere

unread,
Apr 6, 2007, 2:08:21 PM4/6/07
to django...@googlegroups.com
At least the auto_now and auto_now_add options are much better handled
by overwriting a models save method

class MyModel(models.Model):
self.created = models.DatetimeField()
self.modified = models.DatetimeField()

def save(self):
if not self.id:
self.created = datetime.datetime.now()
else:
self.modified = datetime.datetime.now()

super(MyModel, self).save()

Henrik Lied

unread,
Apr 6, 2007, 2:10:17 PM4/6/07
to Django users
Yeah, you're right about that. Your example works best with
editable=False, I'd say.

James Bennett

unread,
Apr 6, 2007, 2:22:04 PM4/6/07
to django...@googlegroups.com
On 4/6/07, Henrik Lied <henri...@gmail.com> wrote:
> Is this removed without a substitute?


* auto_now_add is best done by overriding 'save' to fill in the date
* auto_now can easily be handled by a callable default value that
fills in datetime.datetime.now or datetime.date.today.
* LazyDate is best emulated by a callable which uses 'today' or 'now'
or -- in the case of relative dates/times -- uses timedelta.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

Reply all
Reply to author
Forward
0 new messages