Hi folks --
Over the past few weeks, the core development team have been
discussing how we can streamline our process to get more work done
quicker. It's pretty clear that the bulk of the community wishes
Django could move forward a bit faster [1], and we'd like to be able
to deliver more awesomeness in less time. Ultimately, the goal will be
to put out releases quicker, hit our deadlines more accurately, and be
able to respond to community suggestions and patches in a more timely
manner.
[1] This isn't unique to Django, of course; almost every open
source project wishes they could release more features more quickly.
One way that we'd like to improve our speed is by modifying our
existing backport policy. To refresh your memories, right now we
backport any non-feature-containing patches to the previous release.
So if we fix a bug on trunk, we backport the bug fix to the 1.3.X
branch, where it would become part of the 1.3.1 release. This is a
fair bit of work: it basically means we have to fix each bug twice.
The core team has come to a rough consensus and we're planning to drop
this backport-everything policy. Instead, we'll only backport critical
patches. That is, we'd only backport patches for:
* Security issues.
* Data-loss bugs.
* Crashing bugs.
* Major functionality bugs in newly-introduced features.
In other words, we'd basically only backport bugs that would have
prevented a release in the first place.
Practically, this means that if there's a minor bug in 1.3 -- for
example, #15795, a bug with the representation of RegexURLPattern --
the fix *will not* be applied to the 1.3.X branch, and thus no 1.3.*
release will contain the fix, even if it's fixed in trunk. To get the
fix for these bugs, users will have to upgrade to 1.4.
The upside, of course, is that bug fixes will be quicker to apply, so
we can fix more bugs, so we can get that 1.4 release out sooner [2].
Additionally, this'll give users more of an incentive to upgrade to
the latest-and-greatest. This means that they get new features, and we
(the development community) get to focus more clearly on moving
forward, not maintaining older releases.
[2] Look for a proposed release date soon. Spoiler alert: it's
sooner than you think.
We'd like to make this change effective immediately, but we also don't
want to just issue this change by fiat. So we're requesting comments
and feedback on this change. Do you like the idea? Why or why not?
Will this policy make it more likely you'll contribute? Less likely?
Thanks!
Jacob
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
