Charm Store Series and Ubuntu Release

Clint Byrum clint at ubuntu.com
Tue Aug 28 21:02:20 UTC 2012


Excerpts from Gustavo Niemeyer's message of 2012-08-28 12:48:39 -0700:
> On Tue, Aug 28, 2012 at 4:33 PM, Clint Byrum <clint at ubuntu.com> wrote:
> > However, asking for MySQL 5.6 is not all that unreasonable of an upgrade.
> > Especially if they were to release it as GA right now, in a year it would
> > be the one people are starting to migrate to. But we can't just make it
> > the default, as that will break peoples' deployments. So we need to decide
> > how and when to introduce breaking changes. Waiting 2 years is too long,
> 
> The point remains: never freeze doesn't mean do unreasonable upgrades.
> LTS are also supposed to be stable for juju, and if experimenting with
> new releases is wanted, pick a non-LTS follow up to play with.
> 

We agree. I am suggesting that we support exactly that!

> > The overlay is meant to provide an easier way to use the dev releases.
> > Its taken from the way Debian experimental works. Its likely that a large
> > portion of the charms will "just work" in the new release, so we can
> > just keep using the LTS charms without changing them and without going
> > through the trouble of copying branches/merging/auto-pushing or anything.
> > Just assume, if there's no charm X in this release of the charm store,
> > then use charm X from the last LTS.
> 
> I'm -1 on this. If nobody tests and blesses something to be working in
> a new release, let's not suggest it works and let people find out by
> being burned that it doesn't. If we don't have the man power to
> maintain inter-LTS releases, it's better to simply not do them than to
> be optimistic and hope for the best. This would burn both the non-LTS
> Ubuntu releases and juju itself for no good reason.

Nobody said we wouldn't test it, just that the LTS version will be left
untouched unless it needs changes, and that minor improvements will land
in the LTS, not just in the new dev release.

We will start running all automated charm tests as soon as the new release
has bootable cloud images (alpha1 or 2 usually) and we'll adapt charms
as necessary for changes.

My point is simply that if we do it the way Ubuntu does it, where the
whole collection of released charms is frozen and rolled forward to
the new release of the charm store, things get more complicated because
we're far more likely to have work originate in the LTS, not the current
inter-LTS or even in-development release.

We can also just do this using bzr push to the other releases after
tests pass and as long as the branches have not diverged. I just figured
changing the way we view the repos, instead of hacking them into a shape
we like, is a simpler task. Perhaps that was misguided though.

Either way, what we want is for improvements in the version of Ubuntu
that people are using the charm on to be the norm.



More information about the Juju mailing list