On Mon, 2011-01-03 at 10:54 +0100, Didier Roche wrote: > * I think Michael is referring here to template upgrade (upgrade.py in > ubuntu-application directory). This one can be handled by the policy we > want : LTS to LTS is a must IMHO. In addition to this, as we handle the > check by increasing level like: > > if version < 0.1: > […] > > if version < 0.2: > […] > > if version < 0.3: > […] > > Let's say we were at 0.1, we will then upgrade to 0.2 and then to 0.3 in > a row, so it's not an issue there.
But I had a realization the other day. Sunsetting old project-root versions can't really work. Let's say we do a project-root refactoring in version 0.5. This refactoring is unrealistic to do as part of an upgrade, so we add template code that handles dealing with both versions of the project-root (0.4 and 0.5). User Adam makes a project in 0.4, then upgrades to 0.5 (leaving him with unrefactored code). User Betty makes a project in 0.5. If we *ever* sunset the deal-with-0.4-version-of-project-root template code, Adam's project no longer works. So when we do something that can't be upgraded, we either need to add template code to deal with all versions of the codebase *ever* or find a way to make it upgradeable. This led me to the python_quickly module idea, to try to reduce our maintenance surface area. -- mterry _______________________________________________ Mailing list: https://launchpad.net/~quickly-talk Post to : quickly-talk@lists.launchpad.net Unsubscribe : https://launchpad.net/~quickly-talk More help : https://help.launchpad.net/ListHelp
