I'd like to kickoff the discussion on the timetable and process for the
1.8 release. I am also volunteering
to be the release manager.
First, a retrospective on the 1.7 release with planned release dates and (actual):
Jan. 20: alpha (Jan. 22)
March 6: beta (March 20)
May 1: RC (June 26)
May 15: final (Sept. 2)
One
observation I have is that each stage of the release does not really do
a good job at accurately reflecting our belief about the quality of the
code. For example, we have an "alpha" in order to have a major feature
freeze, but we still allow a significant amount of minor features (3
months worth in the last release) such that the alpha and beta are
hardly comparable. Likewise, we had little confidence that the "RC"
would actually be released without further changes, but rather we needed
to do the release in order to get to the stage where we would only
backport release blocking bugs. Therefore, I am going to propose
returning to a process that is closer to what's documented in the
Release cycle docs [1]. The idea is to front-load all feature work to
pre-alpha so that we can become more conservative with backports sooner.
Here is my proposed schedule:
Jan. 12: alpha
- Feature freeze including minor features (minor features were allowed until beta in the past)
- fork stable/1.8.x from master (in the past we forked after beta, but
now that we'd no longer accept minor features after alpha, we'd need to
fork sooner).
- I picked this date since it is after the end of the
year when I imagine many people are on holiday and therefore able to
contribute more to open source.
- Non-release blocking bug fixes may be backported at the committer's discretion after this date.
Feb. 16: beta
- Only release blocking bugs are allowed to be backported after this date.
- Aggressively advertise it for testing
March 16: release candidate
- Hopefully a true release candidate. If there is still a consistent
stream of release blockers coming in at this date; we'd release beta 2
to encourage further testing and push the release candidate date out ~1
month.
March 30: final
- Release a final as long as the
release blocker stream is sufficiently low. If not, give an update
about the status and make a plan as to how to proceed from there.
On
a related note, I believe we should give some guidance on our thinking
regard LTS. Currently our docs say, "Django 1.4, supported until at
least March 2015." If we adopt 1.8 as the next LTS, I propose to support 1.4 until 6 months after 1.8 is released, which would be at least September 2015. Like 1.4, we'd advertise LTS support for 1.8 for at least 3 years after it's released with a decision on the next LTS to be made as we approach that date.
Feedback on the proposed schedule and handling of the LTS cycle would be appreciated!
If you have any major features you plan to shepherd for this cycle, please ensure they are listed on the roadmap:
https://code.djangoproject.com/wiki/Version1.8Roadmap[1]
https://docs.djangoproject.com/en/dev/internals/release-process/#release-cycle