Juju Formal Release Process

Registered by Clint Byrum on 2012-04-18

Rationale:
A formal Juju release processes is needed in order to keep the high speed of
feature development without driving our users away.

This thread proposes a release process for Juju:
https://lists.ubuntu.com/archives/juju/2012-April/001431.html

Goal:
Define and implement a Juju release process that fits with in the Ubuntu release process.

The basics:
* Keep it simple
* 6 weeks of open trunk
* 1 week of stabilization
* 1 week of testing/critical fixing reserved
* Aim to drop releases before FeatureFreeze in Ubuntu
* Release series minor version bumped if backward incompatible changes are made
* Semantic versions adopted (starting at 0.5.0 which is the version of juju in lp:juju when release process starts)

Blueprint information

Status:
Complete
Approver:
Antonio Rosales
Priority:
High
Drafter:
Ubuntu Server
Direction:
Approved
Assignee:
Clint Byrum
Definition:
Approved
Series goal:
Accepted for quantal
Implementation:
Informational Informational
Milestone target:
milestone icon ubuntu-12.10
Started by
Antonio Rosales on 2012-07-11
Completed by
Clint Byrum on 2012-12-07

Related branches

Sprints

Whiteboard

python two more milestones before maint:
galapagos we'll try the process above
honolulu

What are the options for 12.10 release to allow the go and juju ports to coexist
v2.0.0 go port
use alternatives?
use completely separate namespace? (juju and juju-dev) (juju and juju-2.0)

Is it time to version the charm api as part of this?
specify minimum juju version to work (easier with `juju --version` working)

treat changes as SRUs and backport to python version (?)

worth keeping patch-level in the version... x.x.x

actions
implement this versioning scheme in go juju
spec to allow charms to depend on juju versions BLOCKED on go port
toolchain support for this versioning scheme

not related but
[clint-fewbar] charm proof should complain about unknown keys in metadata.yaml
juju reject charms with invalid metadata

User Stories:
Juju ninja is developing new feature X and would like to land the feature without impacting the stability for current Juju users. Furthermore, this ninja would also like more insights into how feature development and Juju stability work is progressing in relation to the current Ubuntu release cycle.

 Assumptions:
n/a

Test Plan
n/a

Release Note:
None

(?)

Work Items

Work items:
implement this versioning scheme in go juju: DONE
create spec to allow charms to depend on juju versions: INPROGRESS
[jimbaker] implement charm versioning in python: DONE
implement charm versioning in go: POSTPONED
juju to warn on invalid metadata: POSTPONED

Dependency tree

* Blueprints in grey have been implemented.