Public SourceMage Discussion List

[flux <flux AT sourcemage.org>]

David Haley (khoralin AT gmail.com) wrote [11.06.17 01:18]:
> 
> On Jun 14, 2011, at 3:45 PM, George Sherwood wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On Tue, 14 Jun 2011 12:23:55 -0500
> > David Haley <khoralin AT gmail.com> wrote:
> > 
> << snip >>
> 
> > At one time I was looking at this also and leaning toward you 2nd
> > option (removing the oldest version) and making the current the default.
> > 
> > The issue that I ran into though, is the fact that it appears they
> > changed to the build system (I think cmake) if I remember correctly.
> > Many of our current options are not valid and it really is a re-write
> > of the spell from the ground up or you are going to have to maintain
> > both build methods in one spell which seemed to all a lot of clutter
> > and will make maintenance very difficult.
> > 
> That being said if build requirements are not changes due the move upstream 
> that makes me want to lean even more to starting a new spell from scratch. 
> I agree that if we go the two separate paths it is going to be difficult to 
> maintain.
> 
> > Given that I was tempted to just renaming the old spell and building a
> > new mysql spell from scratch with the new build system and new options.
> 
> I am leaning away from having older spells for things in the long run. I 
> would like to propose that we use only a single version spell and write it 
> new to handle the new build environment in Test. We leave Stable as it is 
> for the moment, but, when the next branch comes out I would like to 
> (thinking long-term) we would nuke the multi-version spell in Stable, move 
> what would no be new to Stable, and update the single version spell 
> accordingly in Test.

I personally don't use MySQL, but I have a concern here consisting of
two words: upgrade path. If you simply drop the older versions, anyone
who is using the mysql path will be upgraded (via a sorcery
system-upgrade, for example). Does the new version break backward
compatibility in some way? Does it do so in a way that is easy to fix,
as long as the user is warned? Does it do so in a way that is a real
pain to fix?

If the spell can be upgraded easily without damaging a running system,
then I see no problem with just dropping the older versions. If an
upgrade would require damage control, then I think more thought needs to
go into how it would be handled. Having separate spells would mitigate
this problem, but only for the 5.1<->5.5 split, so the problem could
surface again after 5.5. Will we create a new mysql spell for each
split? How long will we keep each one around?

I know that as a distro we tend away from having hard set policies, but
the question of spell versioning has come up often enough that I think
it's time we come up with policies for it. There are situations like
this where it will be impossible to have a best-case scenario. If we
have a policy that clearly states how we will handle it, then both
spell-writers and users will know what to expect. Then when an update
causes a big change, we can still do the update but with sufficient
warning to the end user per the policy-defined update process (whatever
that ends up being). This will also require clearly defined
communication plans/channels that users can be aware of. That way we
aren't caught in limbo as developers, and users don't get shafted
because they'll know what to expect.

+2 cents

-- 
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgp9xUTsD1E2G.pgp
Description: PGP signature