1.16 Release

[Martin Pool]

2009/6/11 John Arbash Meinel <john at arbash-meinel.com>:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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.

Well, yes, that is basically what I was trying to say.  Or in other
words: the on-disk format marker (also shown when the format is
unrecognized) should change when the format changes and not otherwise.

We don't know with total certainty at the time we release 1.16 whether
the format code will turn out to have bugs, or whether we'll need a
new format sooner or later.  So I'm trying to avoid making commitments
about that in the on-disk string.

If 1.16 turns out to be buggy and we don't want people using it
anymore the best thing seems to be to tell them to upgrade, and maybe
to put out a 1.16.1 that'll make it easy and low-risk.  We can't do
anything in the 1.16 release that will let us stop people using it in
future.  (Ok, peanut gallery, phone home is technically possible but
let's be serious.)

> 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.)

So let's certainly look at them for either 2b (if it's compelling to
do for 2.0) or 3a.  But the bar for pre-2.0 changes is getting higher.

-- 
Martin <http://launchpad.net/~mbp/>