On 20 February 2016 at 03:47, José Antonio Rey <j...@ubuntu.com> wrote:
> Hello,
>
> In approximately two months, Xenial is going to be released. Once that
> happens, we are going to have three supported LTS releases: precise, trusty
> and xenial.
>
> I know that there is some people that have both precise and trusty charms.
> However, if they want to move their charms to xenial, they are going to have
> to maintain not two, but three charms. And if we want to have the latest in
> all charms, then features and software versions would have to be backported
> all the way to precise, which may complicate things a bit more.
>
> I'm wondering, would it be suitable for us to establish a process where a
> charm author decides to no longer maintain a charm in an old but supported
> release and just move that specific series charm to ~unmaintained-charms? I
> think it's better to start thinking on this now, before it gets too close to
> release time.
>
> Happy to hear all your comments/suggestions on this.

I already have charms with deprecated precise branches, used for some
very old legacy installs.

With the 2.0 release and charm store updates, I will also want to
deprecate the trusty branches in favor of a series-independent branch.
I've already started this, moving the PostgreSQL source layer to
launchpad.net/postgresql-charm.The trusty bzr branch will just be a
hindrance when it is no longer needed for ingestion into the charm
store.

It is my understanding that the charm store will accept the series
independent branch and produce cs:trusty/foo series dependent blobs
for older Juju clients. There is still an open bug about allowing Juju
1.25 to deploy series independent branches or local charms without
hacking (https://bugs.launchpad.net/juju-core/+bug/1545686, not a huge
issue since with a local branch you can easily hack metadata.yaml).

-- 
Stuart Bishop <stuart.bis...@canonical.com>

-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Reply via email to