Open Stack

>>  3. Build the controls into our process with a way of storing the
>>     current release cycle information to only allow contract’s to
>>     occur at a set major release and maintain the column in the model
>>     till it is ready to be removed major release + 1 since the
>>     migration was added.
>>
>>
>> Personally, for ease of development and functionality, I think the
>> best option is the 3rd as it will not require reinventing the wheel
>> around data loading and handling of already loaded data models that
>> could affect ORM queries.
> 
> Well one advantage to the way "contract" is totally automated here is
> that as long as the ORM models have a column X present, "contract" won't
> remove it.    What problem would storing the release cycle information
> solve ?  (also by "store" you mean a DB table? ).

Tying this to the releases is less desirable from my perspective. It
means that landing a thing requires more than six months of developer
and reviewer context. We have that right now, and we get along, but it's
much harder to plan, execute, and cleanup those sorts of longer-lived
changes. It also means that CDers have to wait for the contract to be
landed well after they should have been able to clean up their database,
and may imply that people _have_ to do a contract at some point,
depending on how it's exposed.

The goal for this was to separate the three phases. Tying one of them to
the releases kinda hampers the utility of it to some degree, IMHO.
Making it declarative (even when part of what is declared are the
condition(s) upon which a particular contraction can proceed) is much
more desirable to me.

That said, I still think we should get the original thing merged. Even
if we did contractions purely with the manual migrations for the
foreseeable future, that'd be something we could deal with.

--Dan