Planning juju 0.7 release

Kapil Thangavelu kapil.thangavelu at canonical.com
Tue Mar 12 17:52:03 UTC 2013


On Tue, Mar 12, 2013 at 1:28 PM, Clint Byrum <clint at ubuntu.com> wrote:

> Excerpts from Kapil Thangavelu's message of 2013-03-12 08:01:02 -0700:
> > On Tue, Mar 12, 2013 at 7:36 AM, Martin Packman <
> > martin.packman at canonical.com> wrote:
> >
> > > I propose cutting a release from pyjuju trunk this Thursday, and also
> > > releasing new 0.6 and 0.5 minor versions at the same time.
> > >
> > >
> > Sounds good. There's a mechanical issue here though i'd like to delve
> into
> > a bit more. There are two release branches in addition to trunk.
> Currently
> > trunk is backwards compatible to 0.5.2. Currently most bug fixes have
> only
> > been on trunk as well, so would either need to backported (value?) or
> have
> > those releases cut from trunk subject to some additional compatibility
> > testing (client to env).
> >
>
> Does this work?
>
> * install 0.5.2
> * juju bootstrap a local environment
> * upgrade to trunk
> * juju deploy xyz into that env
>
> My guess would be no, but I've not tried this.
>
>
Considering the changes you made to the local env, which were great btw,
no, but yes that should work for other providers. Considering local envs
don't survive restarts ie non persistent, i'm not sure that its a
significant issue.



> > Also by release is there any intent  to update distro versions / srus on
> > any of these?
> >
> > > This would include the recent hook serialisation change, removal of
> > > the orchestra code, JUJU_ENV_UUID support, and lots of bug fixes. It
> > > would not include any other exciting, compatibility breaking, changes
> > > that Kapil might have up his sleeve.
> > >
> > >
> > i've been pretty careful to avoid anything compatibility breaking landing
> > on trunk, as there are too many users on the trunk ppa for that not to
> be a
> > disaster.
> >
>
> The disaster is that users are on the trunk ppa.


its spilled milk, but given the resources available, it was an expedient
way to get fixes out to users quickly. ie. rather than attempting to
maintain multiple releases branches and multiple ppas we just kept
compatibility.

cheers,

Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20130312/6796086b/attachment.html>


More information about the Juju mailing list