quickly-talk team mailing list archive

[Michael Terry <michael.terry@xxxxxxxxxxxxx>]

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