[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libguestfs] Proposed change in the version numbering system



At the moment I post new versions when I feel there has been a
significant amount of work and/or time passed since the previous
release.  This however does not give a good indication of the quality
of the release, for example if it includes mainly bugfixes and
stability improvements, or bleeding edge features.

Therefore I would like to propose a change to the way that libguestfs
versions are numbered.  This is modeled on the old Linux kernel scheme.

Each version will be:

  1.X.Y

We won't change the initial '1' unless at some point in the future we
decided to release a non-backwards-compatible libguestfs.  There are
no plans to do this.

X is the "series".  Even number == stable.  Odd number == development.

Y increments on every release in the series.

Because I'm happy with 1.0.89, this will become the first stable
version:

  1.2.0

Thus the next development versions will be:

  1.3.0, 1.3.1, 1.3.2, 1.3.3, ...

During this time we will backport selected bug fixes and stability
improvements (only!) to:

  1.2.1, 1.2.2, ...

At some point when sufficient new features have accrued we will decide
to make a new stable release and a new development series at the same
time:

  1.4.0   (stable release)
  1.5.0   (new development release)

(Note that 1.2.0, 1.4.0, .. themselves might not be stable, since they
are just a fork of a development release, but by continuing
development, finding bugs and backporting them, the 1.2, 1.4, ..
branches should stabilize over time).

I will also add branches in git at the appropriate points.

I will continue to push the latest development version into Rawhide as
quickly as possible, but for released versions of Fedora (eg. the
up-coming Fedora 13) I will stick to stable releases only.

I hope all of this makes sense.  If anyone has any questions or
objections, please follow-up to this message.

Rich.

PS. Sorry that the git repo is still down.  After we moved the server
we had an unexpected hardware problem, and I'm moving the server to
new hardware today.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://et.redhat.com/~rjones/virt-top


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]