[RFC] new format 1.12 (1.11?) enabling EOL & filtered views

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
> Martin Pool wrote (28/10/08) in response to my latest EOL patch:
> 
>>> We still have some disagreement on whether this requires a format
>>> bump or not. Martin and I think not, Robert thinks otherwise. I'll
>>> let Robert and Martin argue that out because I lack the energy to
>>> go over the issue yet again.
>> So, we did, and I agree we should stick with adding new formats when changing behaviour.   The bulk of this code is not tied to that decision, but I think that it does implicitly turn it on for all working trees, and we don't want that.   If we cut that out (and possibly do it in a plugin), I'd be ok to merge this.
> 
> As agreed between Robert and Martin above, a new working-tree
> format is required to land EOL support. I also have a patch that
> supports filtered views - think git's staging area but nicer - that
> needs a working-tree format bump. I therefore want to introduce
> a new format that I'm proposing to call 1.12.
> 
> To be more precise, I'd like to decouple the introduction of this
> from the CHK format related work by doing the following:
> 
> 1. Adding 2 new experimental formats called 1.12preview and
>    1.12preview-rich-root respectively. These formats will be
>    the same as their 1.9 counterparts except that the WT will
>    be (the new) WT5, not WT4.

The standard way of introducing a format that is "experimental" is to
put it into the "--development" series. Say as a "--development5"
format. I don't have a strict problem with your naming, though I may
have gone 1.12-preview...

> 
> 2. Resubmitting the content filtering patch so that it will
>    only work with WT5 trees.
> 
> 3. Submitting my filtered views patch.

Technically the functionality should land before the format, so that we
don't have a someone running a bzr release that doesn't have the
functionality, but does have the format.

That said, --development seems like a fine place to break compatibility
*inside* of a release, so I don't think it has to happen in that order.
I also realize that any manual testing is hard to do if you don't have a
format that lets you do the testing :).

> 
> 4. When 2 & 3 are approved, rename 1.12preview to 1.12 (ditto
>    the rich-root one) and remove the experimental flag.
> 
> If everything goes swimmingly and all that happens before 1.11RC,
> we can call the format 1.11 instead of 1.12. :-)
> 
> How does that sound to everyone?
> 
> Ian C.
> 
> 

The plan seems fine to me. I certainly doubt it will happen for 1.11 :).

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklGcPUACgkQJdeBCYSNAANItACdH9L+Bt73ax9zE+pse9tXdzSU
LXoAoMD8T9fVrHH+EHCPqvIcn/tG5zUx
=NRjn
-----END PGP SIGNATURE-----