Rev 4848: (vila) NEWS section handling clarified in file:///home/pqm/archives/thelove/bzr/%2Btrunk/

[Canonical.com Patch Queue Manager]

At file:///home/pqm/archives/thelove/bzr/%2Btrunk/

------------------------------------------------------------
revno: 4848 [merge]
revision-id: pqm at pqm.ubuntu.com-20091201111614-rphzh10o64wl018g
parent: pqm at pqm.ubuntu.com-20091201102212-n4fvh6frief0fltd
parent: v.ladeuil+lp at free.fr-20091201103350-v0pqnbqrseejyhrz
committer: Canonical.com Patch Queue Manager <pqm at pqm.ubuntu.com>
branch nick: +trunk
timestamp: Tue 2009-12-01 11:16:14 +0000
message:
  (vila) NEWS section handling clarified
modified:
  doc/developers/releasing.txt   releasing.txt-20080502015919-fnrcav8fwy8ccibu-1
=== modified file 'doc/developers/releasing.txt'
--- a/doc/developers/releasing.txt	2009-11-23 22:54:43 +0000
+++ b/doc/developers/releasing.txt	2009-12-01 10:33:50 +0000
@@ -104,12 +104,12 @@
 
 #. Add the date and release number to ``./NEWS``
 
-   What order to we keep here ? By major release or by date ? The bugfix
-   release are likely to occur after the next major release has
-   occurred. The workflow says that we should keep them sorted by release
-   but that may be a bit disturbing for users reading the NEWS. Anyaw we
-   should chose one and document it.
-  
+   Depending on whether you're doing a beta or a bugfix release, you'll
+   have to create a NEWS section for your release in the right
+   place. Most of the time, the new section is at the top of the file
+   (look what have been done for the various 2.0x and 2.1.0bx releases).
+   The rule is to keep the sections sorted by date. You'll need to be
+   cautious when merging back to trunk to respect that.
 
 #. To check that all bugs mentioned in ``./NEWS`` are actually marked as
    closed in Launchpad, you can run ``tools/check-newsbugs.py``::