Hello! I'd like to talk about the intended scope of the upgrade command. Specifically, what sort of promises the Quickly project makes about it.
The two ends of the spectrum are: 1) any change at all needs an upgrade hook 2) no changes ever need an upgrade hook; if users want new code, they can copy and paste Obviously 2 is no good. But I think 1 is also not very workable and we need a middle ground. Let me give some scenarios I'm considering: 1) We add features to project_root. Like /opt or appindicator support. Traditionally, we've added such features upon an upgrade. 2) We refactor project_root. This recently happened when we moved some Window code into a BaseProjectWindow class. Upgrading such a change is very difficult because customizations made could have been made on the refactored code. When I did made this change, I chose not to bother adding an upgrade hook since no functionality was actually added. 3) We fix bugs in project_root. Some sub examples: a) python_name->project_name. I recently fixed a bug in the /opt support where we specified the path as /opt/.../python_name, but it should be project_name. b) png->svg. I have a branch I'm about to propose that reduces the three identical, differently-sized project logos in project_root to one svg. This fixes issues with blurry window icons. So sort of a cross between refactoring and bug-fixing. c) a crasher. Let's say we find a crasher (e.g. attribute error) and fix it. My proposal for promises from the Quickly project: * Project-level features (like /opt and appindicators) will be added by upgrades. * Refactoring will not be guaranteed to be upgradeable. * Severe bugs will be fixed by upgrades. * Upgrades are only guaranteed to work from adjacent stable releases (i.e. from 10.09 to 11.04, but not directly from 10.09 to 11.10). So #1 will be upgraded, #2 wouldn't, #3a would, #3b wouldn't, #3c would. (all bugs are subject to whether they were present in the latest stable release -- the example #3a was only introduced in an unstable release, so I didn't write a hook for it) The reason I'm trying to reduce promises regarding upgrading from any release to any other release is to reduce maintainer burden. Especially if we aren't promising to upgrade refactors. Which would mean that unless we can sunset old code, upgrade logic has to be able to handle any version of project_root ever. That's a place I'd rather not go. It's an open question in my mind whether we should also follow the LTS schedule of Ubuntu and promise working upgrades from Ubuntu LTS to LTS. This would tie the project closer to the Ubuntu project and may not suit the needs of, say, the Fedora project when and if we get templates for them. But it would be useful for Ubuntu users. What do ya'll think of this proposal? -- 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
