Hello Jose, Thanks for bringing this topic up! You make a good point there are going to be three supported LTS releases available to Juju. I do not think we will ask any maintainer to support all three releases. Currently each charm lives in its own release and I would expect the precise charm contains an older version of a service. It does not make sense to me that someone would try to port the latest version of a service to the precise (12.04) charm. If a charm happens to work on multiple releases we are talking about adding support for that in Juju 2.0.
Our current unmaintained process addresses when an author is not responding or maintaining the charms. We should come up with a process for "active" charm developers to deprecate their precise charms. If a charm developer/maintainer wants to deprecate a charm, I have seen someone authors replace the entire readme and metadata with a deprecation warning pointing to the latest version of the charm and get that through the review process. Although I don't expect we will have to do this very frequently, we locked charms to releases so charms would continue to work with the packages that were available in that release of the operating system. I hope that precise charms continue to work in precise, and if that is not the case create a bug and the author can fix the failure or put a depreciated message in the metadata and readme. Did I address the question you were talking about? If not please give us more details. Thanks! - Matt Bruzek <[email protected]> On Fri, Feb 19, 2016 at 2:47 PM, José Antonio Rey <[email protected]> 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. > > -- > José Antonio Rey > > -- > Juju mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
