1.16 Release

John Arbash Meinel john at arbash-meinel.com
Thu Jun 11 04:26:09 BST 2009

Hash: SHA1

Robert Collins wrote:
> On Thu, 2009-06-11 at 12:23 +1000, Jonathan Lange wrote:
>> On Thu, Jun 11, 2009 at 12:18 PM, Robert
>> Collins<robert.collins at canonical.com> wrote:
>>> On Thu, 2009-06-11 at 12:07 +1000, Martin Pool wrote:
>>>> So the bug should probably be called 'non-development format'; stable
>>>> is perhaps something you only know after the fact.
>>>> Are there any more changes needed for it to go into wider testing?  My
>>>> impression is that more code changes are desirable but we don't think
>>>> we need more format changes.
>>> I don't have any changes queued for 2.0 for the disk format. I do
>>> however have code changes where I want to guarantee that only code with
>>> those changes can read the format.
>> Which means that bumping the format name to '2a' is...
>>   (a) fine
>>   (b) tolerable
>>   (c) a huge mistake
> (d) none of the above.
> Its noise IMO, because we are likely if not definitely going to do a
> bump when we make the format be advertised as stable, to ensure that
> only good code is reading and writing to it.
> -Rob

Which is I believe negates some of the point that Martin was
specifically trying to address. (That we can have something that doesn't
require an explicit/expensive? 'bzr upgrade'.)

Perhaps I didn't understand what Martin was saying earlier about naming.
I felt like he wanted to have the on-disk string be unchanged as much as
possible. So even if bzr 1.16 calls it --development7 the string-on-disk
would be the same as bzr2.0's --2.0 format.

What specific changes do you have in mind?

I have some pie-in-the-sky possibilities for disk format changes, but
nothing proven better enough to push any work back. (Stuff like a
127-byte insert window limits the range of subsequent copies, etc.)


Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list