Request to add *release* SVN branch to https://www.djangoproject.com/download/

[sorin]

Problem: because django is not released very often, the current release download may be missing essential patches needed for normal development. One example would be CL# 15911.

For this reason I propose the inclusion of the SVN release branch to the downloads page. By using the release branch a developer will take advantage of using a stable and updated django code.

How to solve?
Edit ​https://www.djangoproject.com/download/ page and add instruction for getting the updated code from ​http://code.djangoproject.com/svn/django/branches/releases/1.3.X/

[Aymeric Augustin]

It could be interesting to have some users on the release branch, because they could detect problems ahead of maintenance releases.

However, this gives us three group of users to support instead of two (stable, trunk). We need to define our policy regarding the release branch first.

Also, at this time, we don't have up-to-date online docs for this branch, which may be a problem.

[Luke Plant]

The docs at ​https://docs.djangoproject.com/en/1.3/ ought to have up-to-date docs for the 1.3.X branch anyway. Since the 1.3.X branch is only getting vital bug fixes, the only differences between the 1.3.X docs and 1.3.0 docs should be corrections.

[Aymeric Augustin]

Upon further thought, I'm going to reject this ticket, because I think it's more likely to cause confusion for beginners than to help power users.

---

First, we're really, really careful about keeping trunk stable and backwards compatible.

Then, if you're running from a SVN checkout, you're already trading stability for features, and you're trusting the framework's developers. If you feel there's a difference between the stability of trunk and of the maintenance branch, you're a power user, and you can certainly figure out where to checkout the maintenance branch.

Finally, I think there are very few cases where running the maintenance branch is better than running a patched release.

The long term goal is to have shorter release cycles, and support as few versions as possible in parallel.