maas-devel team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

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

...

> * We must be very careful when adding new migrations that nobody
> else is working on one too, because one of you must base your
> migration off the other's
> 
> * When amending old release branches (e.g. lp:maas/1.2) we *cannot*
> add new migrations to it on their own, we *must* add it to trunk
> and backport all the missing trunk migrations.  If this is not
> done, it will break upgrades between releases.
> 
> So, please be very careful when adding database migrations.
> 
> Cheers.
> 

I agree that we need to be careful. I will say that I experimented
with what works in my last database patch. I actually created an
0043-* in the 1.2 branch. And it actually applied properly when I
upgraded to the trunk series by just merging it with the same name.
What *didn't* work is if I created it on trunk, and then just directly
backported it.

I'll try to give examples of what I tried:

1) Create 0043 in branch 1.2. Merge that into trunk which also had an
   0043 patch and an 0044 patch.
   Upgrade worked correctly from 1.2 => trunk.

2) Trying to simply rename 0043 => 0045 in trunk fails because the DB
   doesn't think it has the patch and tries to apply it twice

3) Creating the patch as 0045 in trunk, and then putting just that into
   1.2. It successfully migrates 1.2, adding the 0045 patch. However it
   fails to apply 0043 and 0044 when upgrading to trunk because they
   appear out of order. "migrate --merge" works, but isn't our default
   setting.

4) Obviously creating it on trunk and merging all db migrations works.


So while what you are recommending (4) works, I'd like to point out
that it means we can never land anything on trunk that you don't want
to backport to 1.2 if we ever want to land anything else from trunk on
1.2.

I'd like to point out that (1) seemed to work quite well in my
testing. So we might consider that instead of creating patches on
trunk, and having to backport all pending DB migrations back to 1.2,
we might want to try creating DB migrations on 1.2 and merging up into
trunk where we need it.

I do think it needs a bit more experimenting to make sure it works in
all cases, but it did work when I tried it. And the end result is a
lot easier for developers.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Cygwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCgh2oACgkQJdeBCYSNAANkXwCdGVFhMvaSZR/RHMGhQ+ErVlFb
/MUAnjE3+hPsKa/gv8qt1WBVEzfBmIVl
=rbVL
-----END PGP SIGNATURE-----