maas-devel team mailing list archive

[Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx>]

On Tue, Nov 13, 2012 at 10:06 AM, Julian Edwards
<julian.edwards@xxxxxxxxxxxxx> wrote:
> On 13/11/12 01:51, Raphaël Badin wrote:
>> I think we want to be able to land DB migrations in trunk without having
>> to land them in 1.2.  For that to work, the only way is to:
>> - make sure that *all* the DB migrations are landed on trunk.  (Some of
>> them will be missing in 1.2)
>> - change the packaging to use '--merge' when applying the migrations.
>> The only problem with that would a semantic problem between migrations
>> but that should be picked up during the testing phase.
>
> Technically, I don't actually think it's a big deal to land all
> migrations on 1.2.  All we'd end up with is unused schema parts.  The
> caveat is that we would have to make new schemas compatible with the 1.2
> code base, which again I don't think is much of a problem - we do that
> sort of thing in Launchpad too.
>
> Ultimately, however, I can't see us *needing* to change 1.2 in such a
> way that it requires a migration once we are stable.  I'd also consider
> any change requiring a schema migration to be outside the scope of an
> SRU in all but the most extreme circumstances.

An alternative that nobody has mentioned is a second branch for the
database, which is used as a dependency of both trunk and the
supported release branches. Trunk will of course use the tip, and the
release branches specify which revision is required for the db. I'm
not sure the extra overhead is justified, but it is an option.



-- 
Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx>