Dan Prince wrote: >>> * Migrations added during Folsom release cycle could be compacted >>> during "E" release cycle. TBD if/when we do the next compaction. >> >> An alternative idea would be to do the compaction *prior* to the >> Folsom relase instead of after, so that the cleanest possible >> migration path is presented to non-trunk-chasing users. It could for >> example be a task that's part of spinning up the first Folsom-RC. >> >> Its unlikely that after new migrations are added after the release >> candidate goes out the door (as these are generally associated with >> non-trivial new features, which would have missed the boat at that >> late stage). But if there are any, these would have to be adde to >> the squashed aggregate migration from the get-go. > > I thought about this... but that still leaves only a couple weeks to catch > any issues that might come up in the release candidate phase. Also, using the > RC makes the compaction point a bit more fuzzy for end users who are > following trunk more closely. I do like that it would keep the release tree > cleaner however. > > Performing the compaction after release is sort of a middle ground approach > which should allow us to clean house from time to time but also keep things > stable around release time.
Yes, I've seen a few hard-to-spot regressions caused by migrations in the past, mostly corner cases that affect specific databases, so compacting migrations as the very last step before RC1 generation sounds a bit dangerous to me. It clearly falls in the "clean-up to make code more tidy but can introduce gratuitous regressions without fixing any bug" category, which I prefer to happen early in the cycle rather than late. -- Thierry Carrez (ttx) Release Manager, OpenStack _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
