Proposed release process and 1.0 questions

Hi,

We were talking yesterday on IRC, and it struck me that I should
summarize my thoughts on the release process on the mailing list. It
would be great to get feedback from people along with any issues you
see. Many of these processes are inspired by the Qt/KDE policies in
place, which I think have worked well in those communities.

First a few definitions:

Major release - 1.x.y, 2.x.y etc.
Minor release - 1.0.y, 1.2.y etc.
Patch release - 1.0.0, 1.0.1 etc.

I would like to follow a Linux kernel model for the version numbers. An
even minor version indicates a stable release, an odd minor version
indicates an unstable/beta release. For example 1.0.y would be our
stable release branch, and 1.1.y would become trunk with possible
releases. When it is ready 1.2 would be branched and stabilized.

Minor releases aim to maintain API and ABI compatibility, but can extend
the API. Their is quite a bit of documentation on the Qt and KDE wikis
about what can and cannot be added. A 1.0 binary should be able to link
and run against a 1.2 library, but a 1.2 binary would not be able to
link and run against a 1.0 library as it will likely use new API. If the
ABI has to be broken then the SO version would be bumped.

A patch release, or bug fix release only fixes bugs. No new strings,
features, API etc. Additional translations, documentation etc are all
possible. These releases may not be the most exciting, but should
improve stability and translation coverage. This is in keeping with how
many other projects release. Conservative users can track the stable
releases, more adventurous users could try betas. Due to the way in
which Avogadro binaries are able to be relocated users could easily
install multiple copies of Avogadro in different prefixes such as
/usr/local and their home directory without the need for recompiling
when moving the binaries.

I think our biggest priority should be to fix any big bugs and add more
documentation. I plan to work on documentation tomorrow evening, and
would encourage others to do the same as and when they have time.

Best wishes,

Marcus

Am Dienstag, 20. Oktober 2009 01:57:17 schrieb Marcus D. Hanwell:

I would like to follow a Linux kernel model for the version numbers. An
even minor version indicates a stable release, an odd minor version
indicates an unstable/beta release. For example 1.0.y would be our
stable release branch, and 1.1.y would become trunk with possible
releases. When it is ready 1.2 would be branched and stabilized.

An alternative way would be the “always summer in trunk” version (it means
that trunk is never ever frozen). It was discussed a couple of month ago for
KDE.

cf. page 16ff in this file:

Carsten