[Blueprint servercloud-q-juju-release-process] Juju Formal Release Process

[Antonio Rosales]

Blueprint changed by Antonio Rosales:

Whiteboard changed:
  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

-- 
Juju Formal Release Process
https://blueprints.launchpad.net/ubuntu/+spec/servercloud-q-juju-release-process