Merge lp:~jameinel/bzr/2.0-full-version into lp:~bzr-pqm/bzr/2.0.0

[John A Meinel]

[John A Meinel (jameinel)]

https://code.edge.launchpad.net/~jameinel/bzr/2.0-full-version/+merge/11617

That may be deleted, but the code review summary definitely did *not* have the latest version of my changes.

The basic summary is that it changes

 bzr 2.0

into

 bzr 2.0.0

Which effects things like

 bzr 2.1b1 => 2.1.0b1

It also updates cycle.txt and NEWS, etc for these changes.

This is supposed to land in the 2.0.0 release, so that doing:
  bzr --version

Properly reports 2.0.0 rather than just 2.0.

(And now that we don't have the simple 'Resubmit' option, I really have no clue what the proper hoops I'm supposed to jump through to get the diff to update... :(

[John A Meinel (jameinel)]

> https://code.edge.launchpad.net/~jameinel/bzr/2.0-full-version/+merge/11617
>
> That may be deleted, but the code review summary definitely did *not* have the
> latest version of my changes.

I guess I should have just rejected it, rather than deleting it, as it seems 'gone for good' now... :(

Sorry for the confusion.

[Martin Pool (mbp)]

+1, for 2.0.0, 2.0 and trunk. (Or just merge to 2.0.0 and it can get swept into the others later on.)

review: Approve

=== modified file 'NEWS'
--- NEWS	2009-09-10 06:47:42 +0000
+++ NEWS	2009-09-11 18:28:19 +0000
@@ -3,10 +3,18 @@
 ####################
 
 
-bzr 2.0rc2
-##########
-
-:2.0rc2: 2009-09-10
+bzr 2.0.0 (Not Released Yet)
+############################
+
+* Officially branded as 2.0.0 rather than 2.0 to clarify between things
+  that "want to happen on the 2.0.x stable series" versus things that want
+  to "land in 2.0.0". (Changes how bzrlib._format_version_tuple() handles
+  micro = 0.) (John Arbash Meinel)
+
+bzr 2.0.0rc2
+############
+
+:2.0.0rc2: 2009-09-10
 
 New Features
 ************
@@ -101,11 +109,11 @@
   and Plugins Guide. (Ian Clatworthy)
 
 
-bzr 2.0rc1
-##########
+bzr 2.0.0rc1
+############
 
 :Codename: no worries
-:2.0rc1: 2009-08-26
+:2.0.0rc1: 2009-08-26
 
 This release of Bazaar makes 2a 'brisbane-core' format the
 default.  Most of the work in this release now focuses on bug

=== modified file 'bzrlib/__init__.py'
--- bzrlib/__init__.py	2009-09-10 06:47:42 +0000
+++ bzrlib/__init__.py	2009-09-11 18:25:45 +0000
@@ -65,23 +65,29 @@
     zero for final releases.
 
     >>> print _format_version_tuple((1, 0, 0, 'final', 0))
-    1.0
+    1.0.0
     >>> print _format_version_tuple((1, 2, 0, 'dev', 0))
-    1.2dev
+    1.2.0dev
+    >>> print bzrlib._format_version_tuple((1, 2, 0, 'dev', 1))
+    1.2.0dev1
     >>> print _format_version_tuple((1, 1, 1, 'candidate', 2))
     1.1.1rc2
     >>> print bzrlib._format_version_tuple((2, 1, 0, 'beta', 1))
-    2.1b1
+    2.1.0b1
     >>> print _format_version_tuple((1, 4, 0))
-    1.4
+    1.4.0
     >>> print _format_version_tuple((1, 4))
     1.4
+    >>> print bzrlib._format_version_tuple((2, 1, 0, 'final', 1))
+    Traceback (most recent call last):
+    ...
+    ValueError: version_info (2, 1, 0, 'final', 1) not valid
     >>> print _format_version_tuple((1, 4, 0, 'wibble', 0))
     Traceback (most recent call last):
     ...
     ValueError: version_info (1, 4, 0, 'wibble', 0) not valid
     """
-    if len(version_info) == 2 or version_info[2] == 0:
+    if len(version_info) == 2:
         main_version = '%d.%d' % version_info[:2]
     else:
         main_version = '%d.%d.%d' % version_info[:3]
@@ -96,6 +102,8 @@
         sub_string = ''
     elif release_type == 'dev' and sub == 0:
         sub_string = 'dev'
+    elif release_type == 'dev':
+        sub_string = 'dev' + str(sub)
     elif release_type in ('alpha', 'beta'):
         sub_string = release_type[0] + str(sub)
     elif release_type == 'candidate':
@@ -103,7 +111,6 @@
     else:
         raise ValueError("version_info %r not valid" % (version_info,))
 
-    version_string = '%d.%d.%d.%s.%d' % tuple(version_info)
     return main_version + sub_string
 
 

=== modified file 'doc/developers/cycle.txt'
--- doc/developers/cycle.txt	2009-08-12 06:43:36 +0000
+++ doc/developers/cycle.txt	2009-09-11 18:25:08 +0000
@@ -97,12 +97,12 @@
 
 ::
 
- 2.0 --- 2.0.1 -- 2.0.2 -- ...
+ 2.0.0 --- 2.0.1 -- 2.0.2 -- ...
   \
-   +--2.1beta1 -- 2.1beta2 -- ... -- 2.1rc1 -- 2.1 -- 2.1.1 -- ...
-                                                \
-                                                 \
-                                                  +-- 3.0beta1 ...
+   +--2.1.0beta1 -- 2.1.0beta2 -- ... -- 2.1.0rc1 -- 2.1.0 -- 2.1.1 -- ...
+                                                      \
+                                                       \
+                                                        +-- 3.0.0beta1 ...
 
 
 Starting from the date of a major release: 
@@ -144,26 +144,32 @@
 ---------
 
 The number for a six-month cycle is chosen at the start, with an increment
-to either the first field (3.0) or second field (3.1) depending on what we
-expect to be the user impact of the release.  We expect releases that
-culminate in a new disk format or that require changes in how people use
-the tool will get a new major number.  We can change (forward only) if it
-turns out that we land larger changes than were expected.
+to either the first field (3.0.0) or second field (3.1.0) depending on
+what we expect to be the user impact of the release.  We expect releases
+that culminate in a new disk format or that require changes in how people
+use the tool will get a new major number.  We can change (forward only) if
+it turns out that we land larger changes than were expected.
+
+We will always use the 3-digit form (major.minor.micro) even when
+referring to the initial major release. This should help clarify where a
+patch is intended to land. (eg, "I propose this for 2.0.0" is clear, while
+"I propose this for 2.0" could mean you want to make the 2.0.0 release, or
+that you just want to land on the 2.0.x stable release series.)
 
 
 Terminology
 -----------
 
-Major releases (2.0 or 2.1)
+Major releases (2.0.0 or 2.1.0)
     The big ones, every six months, intended to ship in distributions and
     to be used by stability-oriented users.
 
-Release candidate (2.0rc1)
+Release candidate (2.0.0rc1)
     A preview of a major release, made one or a few weeks beforehand at
     the time the release branch is created.  There should be few if any
     changes from the rc to the stable release.  We should avoid the
-    confusing phrasing "release candidate 2.0rc1 is released"; instead use
-    "available."
+    confusing phrasing "release candidate 2.0.0rc1 is released"; instead
+    use "available."
 
 Bugfix releases (2.0.1)
     Based on the previous major release or bugfix; contains only bugfixes
@@ -175,7 +181,7 @@
 Stable release
     Either a major release or a bugfix release.
 
-Beta release (3.0beta1)
+Beta release (3.0.0beta1)
     Made from trunk every month, except for the month there's a major
     release.  Stable and suitable for users who want the latest code and
     can live with some changes from month to month.
@@ -260,7 +266,7 @@
 Each major release will have one recommended data format which will be the
 default.  The name of the format will indicate which release series (not
 specific release) it comes from: '2a' is the first supported format for
-the 2.0 series, '2b' the second, etc.  We don't mention the particular
+the 2.0.x series, '2b' the second, etc.  We don't mention the particular
 release that introduced it so as to avoid problems predicting precisely
 when it will land.
 
@@ -321,9 +327,10 @@
 only the stable releases.  This is probably better than having them only
 intermittently or slowly ship the monthly releases.
 
-Binary installers should use a version number like '2.0-1' or '2.0beta1-1'
-so that the last component just reflects the packaging version, and can be
-incremented if a new installer is made with no upstream source changes.
+Binary installers should use a version number like '2.0.0-1' or
+'2.0.0beta1-1' so that the last component just reflects the packaging
+version, and can be incremented if a new installer is made with no
+upstream source changes.
 
 
 Code Freeze vs Announcement