> as far as i understand it, django applications are ment to be
> pluggable.. how big are the odds that you'll find two applications
> which would work with the same django trunk revision ?

I didn't mean that your app would stop working at all on any other
revisions. Just that you can "officially certify" that it's known to
work with a certain revision (that you've had a chance to test). Your
users can still use it with future revisions (see below for more
thoughts on this.)

> SCT is not (just) meant as a final product which runs separately, but
> as applications which can be integrated into a django project.. i
> can't force people to use a given revision .. having a release which
> holds for 2-4 months would make things easier imho ..

Not every new trunk commit creates a backward incompability problem.
Furthermore, there are around 4 changes a month that are backward-
incompatible (based on the list here: 
http://code.djangoproject.com/wiki/BackwardsIncompatibleChanges)
and not all of them affect everyone who's using a trunk release.

As an example, the change from FloatField to DecimalField in trunk
revision 5302 would only prevent your app from working if your app has
models that use that field.

Perhaps, you want to consult with other app writers (django-tagging,
django-voting, registration, etc.) and see how they handle this issue.



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to