+1 to committing our migrations before the alpha. I like the idea of having new migrations in the PR that involves model changes.
I don’t know what kind of conflicts should arise but the only time I think we should consider recreating all the migrations is after we do a release where we don’t support upgrades (e.g. the alpha release of Pulp 3.0). David On Thu, Sep 14, 2017 at 2:26 PM, Austin Macdonald <[email protected]> wrote: > Today I filed and fixed https://pulp.plan.io/issues/3012, which is an > issue related to creating the migrations in the right order. It is a > temporary problem that we will have until we take the step of committing > the migrations to version control. > > The reason migrations are not in git right now is that the models have > changed often. > > Reasons to do this now: > 1) Our models are more stable now. > 2) We don't want teach our alpha users how to use django migration tools. > 3) We permanently solve the migration order issue. > > If we do commit them, we will still be flexible to change our models. In > the past, upgrading from an alpha or beta to a new alpha or beta is not > supported, so I think it would be acceptable to blow away the migrations > and create all new ones all the way up until 3.0 GA. In fact, it would be > nice to have a minimal set of migrations at that time without any artifacts > of our development up to that point. > > If everyone agrees that now is the time, how should we do it? It seems to > me like we should include new migrations with each model change in the same > PR. We start fresh only if there are conflicts or if we want to do a > "fresh" release. > > _______________________________________________ > Pulp-dev mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/pulp-dev > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
