Juju Formal Release Process
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:/
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
- Milestone target:
-
ubuntu-12.10
- Started by
- Antonio Rosales
- Completed by
- Clint Byrum
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.
