Changes between Initial Version and Version 1 of Version1.3Roadmap

Timestamp:

Sep 30, 2010, 9:56:42 AM (15 years ago)

Author:

Russell Keith-Magee

Comment:

Added 1.3 roadmap

Version1.3Roadmap

@@ +1 @@
+{{{
+#!text/x-rst
+
+==================
+Django 1.3 Roadmap
+==================
+
+This document details the roadmap for the release of Django 1.3. 
+
+What will be in Django 1.3?
+===========================
+
+Whatever gets committed by November 29th!
+
+Django 1.3 will be a time-based release; any features completed and checked in by the feature freeze deadline (November 29th) will be included. Any that miss the deadline won't. 
+
+The main focus of major feature development will be features that didn't make the cut for v1.2, such as:
+
+ * #12012 - Logging
+ * #6735 - Class-based generic views
+
+However, the focus of Django 1.3 isn't to add lots of big new features. The last two Django releases have added lots of features, and the little things have suffered as a result. The intention of the 1.3 release is to focus on fixing bugs and adding the low priority and minor features that haven't got as much attention.
+
+Schedule
+========
+
+Major milestones along the way to 1.3 are scheduled below. See `Process`_,
+below, for more details.
+
+==================  ===========================================================
+October 18, 2010        Django 1.3 alpha; major feature freeze.
+
+November 29, 2010    Django 1.3 beta; complete feature freeze.
+
+January 10, 2011       Django 1.3 RC 1; translation string freeze.
+
+January 17, 2011       Django 1.3 final (or RC 2, if needed).
+==================  ===========================================================
+
+Process
+=======
+
+James Bennett, as the release manager, will be in charge of keeping the
+schedule. He'll keep track of who's working on what issues so that bug reports
+can be efficiently routed; he'll also nag, cajole and (if necessary) berate
+developers who are in danger of missing deadlines.
+
+Feature freeze / Alpha 1
+------------------------
+
+As with v1.2, all major features must be committed by the Alpha 1 deadline. Any
+work not done by this point will be deferred or dropped.
+
+Beta 1
+------
+
+As with v1.2, Beta 1 marks the end of *any* feature work. Only bug fixes will be
+allowed in after this point.
+
+RC 1
+----
+
+Again, no change here. RC 1 will, Murphy willing, be a true release candidate:
+1.3 final should be identical to RC 1. RC 1 also marks string freeze;
+translators will have roughly a week to submit updated translations for
+inclusion in the final release.
+
+Release
+-------
+Django 1.3 final will ship one week after the last RC. Hopefully we'll only need
+a single RC, so, the final release will follow roughly a week after RC 1. If
+blockers are found, another RC will be released instead.
+
+How you can help
+----------------
+
+The only way we'll meet this deadline is with a great deal of community effort.
+To that end, here's how you can help:
+
+    * Read the `guide to contributing to Django`__ and the `guide to Django's
+      release process`__.
+      
+      These guides explains how our process works. where to ask questions,
+      etc. It'll save everyone time if we're all on the same page when it
+      comes to process.
+      
+    * Work on features.
+
+      The joy of Open Source is that nobody gets to tell you what to do; you
+      can scratch whichever itch you like. However, if you work on big feature
+      items, you should expect that your patch won't get checked in until 
+      after 1.3.
+    
+      Get in touch with the lieutenant/committer for the feature you'd like
+      to work on and help out. Or just find open tickets and start submitting
+      patches!
+
+    * Write and review patches.
+
+       There are plenty of tickets already on the `1.3 Milestone`__ that either don't have
+       patches, or have patches that need review. Writing, reviewing and
+       improving patches is the best way to make sure that 1.3 has as few bugs as
+       possible.
+      
+    * Attend a sprint (in person or in IRC).
+    
+    * Organize tickets.
+
+       * Feature tickets should go in the "1.3 alpha" or "1.3 beta" milestone. 
+       
+         Which one? Well, major changes must be made before the alpha, and
+         minor feature changes before the beta. So "major" feature additions
+         go in the alpha milestone, and minor additions in the beta one. If
+         you're not sure, then the feature is minor.
+         
+         **Bugs** are **not** to be part of these milestone; any bug is a
+         candidate for fixing and should be left un-milestoned. The exception
+         is bugs in features added for 1.3; those should be in the "1.3"
+         milestone.
+
+    * Test the release snapshots (alphas, betas) against your code and report
+      bugs.
+      
+      We need *lots* of testers if we're to have a bug-free release. Download
+      a snapshot or an SVN checkout and give it a try!
+    
+__ http://docs.djangoproject.com/en/dev/internals/contributing/
+__ http://docs.djangoproject.com/en/dev/internals/release-process/
+__ http://code.djangoproject.com/query?status=new&status=assigned&status=reopened&milestone=1.3  
+
+}}}