Open Stack

Hi Folks,

I just want to scare up some ideas on what the versioning scheme
should look like for the nova virt library discussed previously[1]
(primarily for ceilometer use).

Initially I had in mind something like the scheme used for API
extensions, i.e. a date-based version that's independent of the
primary nova version cycle.

However on looking into the API extensions in more detail, I see
that it's intended to be interpreted in relation to the primary API
versioning, which is clearly not applicable in this case.

So general principles for the lib version scheme would include:

- library API versioning is expected to be slow-moving,
  possibly spanning several release cycles, hence could be
  decoupled from the main year.quarter version identifiers 

- the API might be extended in purely additive ways, as we may
  decide to expose some new aspects of the virt abstraction,
  without breaking existing clients

- the internals of the API may be patched from time to time
  in backward compatible ways that do not break the consumer

Would triplet-based versioning loosely based on the above
be too simple minded? 

e.g. nova-virt-1.0.1 for the first patch fix over the initial
release, or nova-virt-1.2.0 for the next additive change.

The other thing to consider here would be the release mechanics,
i.e. whether it's sufficient for library releases to be
piggy-backed alongside the main nova releases, or whether
we'd need to decouple this process also (so that a library
release can happen completely independently).

Thoughts?

Cheers,
Eoghan


[1] http://wiki.openstack.org/EfficientMetering/FutureNovaInteractionModel#option_5