Rev 4705: (jam) Bring in a couple small patches from the 2.0 branch (such as in file:///home/pqm/archives/thelove/bzr/%2Btrunk/
Canonical.com Patch Queue Manager
pqm at pqm.ubuntu.com
Fri Sep 18 17:04:58 BST 2009
At file:///home/pqm/archives/thelove/bzr/%2Btrunk/
------------------------------------------------------------
revno: 4705 [merge]
revision-id: pqm at pqm.ubuntu.com-20090918160454-ag1zd9txn44prlye
parent: pqm at pqm.ubuntu.com-20090918103234-r44grr68i0lcfhrf
parent: john at arbash-meinel.com-20090918150809-t4kow9vdc8mosvkw
committer: Canonical.com Patch Queue Manager <pqm at pqm.ubuntu.com>
branch nick: +trunk
timestamp: Fri 2009-09-18 17:04:54 +0100
message:
(jam) Bring in a couple small patches from the 2.0 branch (such as
the 2.0.0 fix)
modified:
NEWS NEWS-20050323055033-4e00b5db738777ff
bzrlib/__init__.py __init__.py-20050309040759-33e65acf91bbcd5d
bzrlib/symbol_versioning.py symbol_versioning.py-20060105104851-9ecf8af605d15a80
bzrlib/tests/test_plugins.py plugins.py-20050622075746-32002b55e5e943e9
bzrlib/tests/test_symbol_versioning.py test_symbol_versioning.py-20060105104851-51d7722c2018d42b
doc/developers/cycle.txt cycle.txt-20081017031739-rw24r0cywm2ok3xu-1
setup.py setup.py-20050314065409-02f8a0a6e3f9bc70
=== modified file 'NEWS'
--- a/NEWS 2009-09-18 06:06:41 +0000
+++ b/NEWS 2009-09-18 15:08:09 +0000
@@ -2,22 +2,12 @@
Bazaar Release Notes
####################
-bzr 2.0.1
-##########
-
-Bug Fixes
-*********
-
-* Make sure that we unlock the tree if we fail to create a TreeTransform
- object when doing a merge, and there is limbo, or pending-deletions
- directory. (Gary van der Merwe, #427773)
-
-
.. contents:: List of Releases
:depth: 1
-2.1 series (not released yet)
-#############################
+
+2.1.0 series (not released yet)
+###############################
Compatibility Breaks
********************
@@ -173,10 +163,31 @@
* The full test suite is expected to pass when the C extensions are not
present. (Vincent Ladeuil, #430749)
-bzr 2.0rc2
-##########
-
-:2.0rc2: 2009-09-10
+
+bzr 2.0.1 (Not Released Yet)
+############################
+
+Bug Fixes
+*********
+
+* Make sure that we unlock the tree if we fail to create a TreeTransform
+ object when doing a merge, and there is limbo, or pending-deletions
+ directory. (Gary van der Merwe, #427773)
+
+
+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
************
@@ -267,11 +278,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'
--- a/bzrlib/__init__.py 2009-09-16 07:47:47 +0000
+++ b/bzrlib/__init__.py 2009-09-18 14:53:37 +0000
@@ -60,23 +60,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]
@@ -91,6 +97,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':
@@ -98,7 +106,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 'bzrlib/symbol_versioning.py'
--- a/bzrlib/symbol_versioning.py 2009-04-04 02:50:01 +0000
+++ b/bzrlib/symbol_versioning.py 2009-09-15 02:28:34 +0000
@@ -41,7 +41,7 @@
"""Generate a message that something was deprecated in a release.
>>> deprecated_in((1, 4, 0))
- '%s was deprecated in version 1.4.'
+ '%s was deprecated in version 1.4.0.'
"""
return ("%%s was deprecated in version %s."
% bzrlib._format_version_tuple(version_tuple))
=== modified file 'bzrlib/tests/test_plugins.py'
--- a/bzrlib/tests/test_plugins.py 2009-08-21 09:19:11 +0000
+++ b/bzrlib/tests/test_plugins.py 2009-09-18 14:53:37 +0000
@@ -394,13 +394,18 @@
def test_dev_fallback__version__with_version_info(self):
self.setup_plugin("version_info = (1, 2, 3, 'dev', 4)")
plugin = bzrlib.plugin.plugins()['plugin']
- self.assertEqual("1.2.3.dev.4", plugin.__version__)
+ self.assertEqual("1.2.3dev4", plugin.__version__)
def test_final__version__with_version_info(self):
self.setup_plugin("version_info = (1, 2, 3, 'final', 0)")
plugin = bzrlib.plugin.plugins()['plugin']
self.assertEqual("1.2.3", plugin.__version__)
+ def test_final_fallback__version__with_version_info(self):
+ self.setup_plugin("version_info = (1, 2, 3, 'final', 2)")
+ plugin = bzrlib.plugin.plugins()['plugin']
+ self.assertEqual("1.2.3.final.2", plugin.__version__)
+
class TestPluginHelp(TestCaseInTempDir):
=== modified file 'bzrlib/tests/test_symbol_versioning.py'
--- a/bzrlib/tests/test_symbol_versioning.py 2009-03-24 01:53:42 +0000
+++ b/bzrlib/tests/test_symbol_versioning.py 2009-09-15 01:43:42 +0000
@@ -76,11 +76,11 @@
expected_warning = (
"bzrlib.tests.test_symbol_versioning."
"deprecated_static "
- "was deprecated in version 0.7.", DeprecationWarning, 2)
+ "was deprecated in version 0.7.0.", DeprecationWarning, 2)
expected_docstring = (
'Deprecated static.\n'
'\n'
- 'This function was deprecated in version 0.7.\n'
+ 'This function was deprecated in version 0.7.0.\n'
)
self.check_deprecated_callable(
expected_warning, expected_docstring,
@@ -92,13 +92,14 @@
expected_warning = (
"bzrlib.tests.test_symbol_versioning."
"TestDeprecationWarnings.deprecated_method "
- "was deprecated in version 0.7.", DeprecationWarning, 2)
- expected_docstring = ('Deprecated method docstring.\n'
- '\n'
- ' This might explain stuff.\n'
- ' \n'
- ' This method was deprecated in version 0.7.\n'
- ' ')
+ "was deprecated in version 0.7.0.", DeprecationWarning, 2)
+ expected_docstring = (
+ 'Deprecated method docstring.\n'
+ '\n'
+ ' This might explain stuff.\n'
+ ' \n'
+ ' This method was deprecated in version 0.7.0.\n'
+ ' ')
self.check_deprecated_callable(expected_warning, expected_docstring,
"deprecated_method",
"bzrlib.tests.test_symbol_versioning",
@@ -107,10 +108,10 @@
def test_deprecated_function(self):
expected_warning = (
"bzrlib.tests.test_symbol_versioning.sample_deprecated_function "
- "was deprecated in version 0.7.", DeprecationWarning, 2)
+ "was deprecated in version 0.7.0.", DeprecationWarning, 2)
expected_docstring = ('Deprecated function docstring.\n'
'\n'
- 'This function was deprecated in version 0.7.\n'
+ 'This function was deprecated in version 0.7.0.\n'
)
self.check_deprecated_callable(expected_warning, expected_docstring,
"sample_deprecated_function",
@@ -119,7 +120,7 @@
def test_deprecated_list(self):
expected_warning = (
- "Modifying a_deprecated_list was deprecated in version 0.9."
+ "Modifying a_deprecated_list was deprecated in version 0.9.0."
" Don't use me", DeprecationWarning, 3)
old_warning_method = symbol_versioning.warn
try:
@@ -157,7 +158,7 @@
def test_deprecated_dict(self):
expected_warning = (
- "access to a_deprecated_dict was deprecated in version 0.14."
+ "access to a_deprecated_dict was deprecated in version 0.14.0."
" Pull the other one!", DeprecationWarning, 2)
old_warning_method = symbol_versioning.warn
try:
@@ -205,12 +206,12 @@
"""We can get a deprecation string for a method or function."""
self.assertEqual('bzrlib.tests.test_symbol_versioning.'
'TestDeprecationWarnings.test_deprecation_string was deprecated in '
- 'version 0.11.',
+ 'version 0.11.0.',
symbol_versioning.deprecation_string(
self.test_deprecation_string,
deprecated_in((0, 11, 0))))
self.assertEqual('bzrlib.symbol_versioning.deprecated_function was '
- 'deprecated in version 0.11.',
+ 'deprecated in version 0.11.0.',
symbol_versioning.deprecation_string(
symbol_versioning.deprecated_function,
deprecated_in((0, 11, 0))))
=== modified file 'doc/developers/cycle.txt'
--- a/doc/developers/cycle.txt 2009-08-12 06:43:36 +0000
+++ b/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
=== modified file 'setup.py'
--- a/setup.py 2009-09-03 12:10:38 +0000
+++ b/setup.py 2009-09-15 07:39:18 +0000
@@ -411,6 +411,7 @@
includes.append('sip') # extension module required for Qt.
packages.append('pygments') # colorizer for qbzr
packages.append('docutils') # html formatting
+ includes.append('win32event') # for qsubprocess stuff
# but we can avoid many Qt4 Dlls.
dll_excludes.extend(
"""QtAssistantClient4.dll QtCLucene4.dll QtDesigner4.dll
More information about the bazaar-commits
mailing list