Lumiera
The new emerging NLE for GNU/Linux
State Final
Date Mi 09 Mär 2011 02:00:41 CET
Proposed by Ichthyostega <prg@ichthyostega.de>

Define and use a version numbering scheme for all releases, including the development releases. Use the rules of the debian policy as a guideline.

Description

It should be clear right from start how version numbers are to be generated. This numbering scheme should include a pattern for development builds. The Debian policy defines a nice algorithm for ordering extended version numbers, which could be used as a guideline. The sequence of version numbers should be monotonous increasing according to this ordering.

Version number sequence

0.pre.## < 0.01~dev.20YYMMDDhhmm < 0.01 < 0.99 < 1.0~dev.20YYMMDDhhmm < 1.0 < 1.0.1

Specifications

A tagged build is made whenever there is a feature change tangible for users. This might just be a dev release. Contrary to this, a published release is a build expected to be installed and used by the users. Amongst the published releases, we distinguish major and minor and bugfix releases.

  • before we reach alpha status, we don’t create any real releases, just tagged preview builds from time to time. The criteria for reaching alpha status are defined on the roadmap.

  • during alpha and beta status, we don’t differentiate our releases; they are just numbered consecutively with 2 digits (to start with). A release is made whenever there is something significant new or otherwise interesting to try out for the users.

  • besides the releases, we create development snapshot releases, which are just tagged builds.

    • Not every build/check-in gets promoted to such a tagged build; rather there needs to be any reason from the users point of view, e.g. a bugfix we expect to be tried out at least by someone.

    • these development snapshots are an anticipation of the upcoming next release and thus get a numbering derived from this next release (not the previous one).

    • dev snapshots use a timestamp attached with a ~ (tilde char). It is common practice to order a tilde below the release it is attached to (and debian follows this practice)

  • when we decide the application to be stable enough for real use and past the beta phase, we switch over to the usual 3-digit version numbering.

    • major releases start with 1.0 and feature high impact changes, usually linked to some significant breakage of compatibility or some other disruptive event.

    • minor releases may include some new features, but can be considered evolutionary. Their numbers are incremented on the second digit, like 1.1, 1.2, 1.3, 1.4, ….

    • bugfix releases are created when we have serious bugfixes to publish, without any real new features.

  • similar to the practice established in pre-1.0, we can create series of development snapshots working against and anticipating the next major/minor release. We’ll do so for those users interested in following the development more closely. The version numbers for such anticipating snapshots are again created by attaching a timestamp with a ~ (tilde char).

Tasks

  • a debian packaging has been created (✔)

  • the first version was tagged 0.pre.01

Discussion

Pros

  • the format of the version numbers classifies the kind of build

  • the changes in the scheme where chosen to reflect the changed dynamics in pre-alpha, beta and post-1.0

  • the anticipating snapshots fit better into the usual habits of developers: the moment a release is published, it is outdated and uninteresting.

  • this practice with the anticipating snapshots was popularised in by Apache Maven and works well in practice

Cons

  • this visioning scheme might look overengineered at first sight

Alternatives

don’t worry — be happy is what developers usually do with version numbering. Especially not caring for development snapshots might be viable for commercial products; but users of open source software frequently follow the development rather directly; thus it’s a good idea to have a clear numbering for these dev snapshots too.

Alternatively we might consider to use Git SHA-Hashes for the dev builds. But unfortunately, these are rather long and not very mnemonic. We’re better off just adding them to the changelog (as recommended by Debian policy anyway)

Rationale

Many projects face a lot of confusion and bad reputation when they “happen to run into” more widely published releases without any forethought. Users tend to be confused quickly and can’t be expected to understand the details of the development process. Thus we should discuss and set up a unambiguous numbering scheme really early — including the criteria when to use what version number.

Comments

State → Final

considered common practice

Do 14 Apr 2011 03:46:07 CEST Christian Thaeter <ct@pipapo.org>

Back to Lumiera Design Process overview