wintermute-devel team mailing list archive

[Jacky Alcine <jackyalcine@xxxxxxxxx>]

Best I get this out of the way first.

There's a bit of a versioning scheme up on the Synthetic Intellect 
Institute's Wiki, but I guess it's best to address to all developers so 
we'd know. 

Wintermute uses a three-component version scheme, appending occasionally 
version flags such as (alpha, beta, pre-release, and release candidate). The 
first two components represent a typical version system, the left-most, first 
number representing a major version and the following number representing a 
minor version, and another representing a micro version number. The 
definition of  when each value would be incremented is described below:

1. Changes to the micro number only (that is, changes within the same minor 
line) must be both forward- and backward-compatible. That is, the changes 
should be bug fixes only, or very small enhancements to existing features. 
New features should not be introduced in a micro release.

2. Changes to the minor number (that is, within the same major line) must 
be backward-compatible, but not necessarily forward-compatible. It's normal 
to introduce new features in a minor release, but usually not too many new 
features at once.

3. Changes to the major number mark compatibility boundaries. A new major 
release can be forward-and backward-incompatible. A major release is 
expected to have new features, and may even have entire new feature sets.

(Those three points are the words of Karl Fogel, a former maintainer of CVS 
and developer of Subversion from his book "Producing Open Source Software". 
It's freely found on the web but I have a PDF if anyone wants. It's some 
good stuff.)

A change is backward-compatible when one upgrades to a later version of 
Wintermute (let's say 2.4.2) and is able to work with later versions of 
Wintermute's libraries (like 2.4.0) or other Wintermute services across the 
AngelNet. However, by upgrading to 2.4.2, the older libraries would be 
unaware of the new code in 2.4.2's core, in the sense that the code in 
2.4.0 wasn't written to compliment the enhancements of 2.4.2, but wouldn't 
break any currently existing features. A change is forward-compatible when 
an downgrade can be done (from 2.4.2 to 2.4.0) and it's able to maintain 
the features found in 2.4.2 (mainly because the feature set hasn't changed 
from 2.4.0). 

With this said, the micro version is reserved for minor, tiny bugs, the 
minor version is for bugs that don't necessarily change feature ability or 
the modification or fixing of an existing feature, or introduce a new feature 
subtly without losing capability with its predecessor, and the major 
version being a drastic change that can break compatibility with previous 
versions.

The following schemes are valid:

	* 0.0.1 alpha
	* 0.0.3 RC (release candidate)

Occasionally, as Wintermute develops, we might have security issues (files 
being written or deleted from sensitive areas, sockets left open) reported 
as bugs. We have to do our best to defer any changes we expected for the 
current release and address the security bug. For example, if we're on 
1.1.3, and we're not due to release another micro version for a while, then 
1.1.4 would be released as soon we've tested the hell out of the security 
bug to ensure that it's squashed and release it. Anything we wanted for 
1.1.4 would be released in 1.1.5.

In order to efficiently use this system, hopefully when I can get to be on-
line more often, and when our developer base grows (from 2? to about 6 or 
10), we'd enforce the following:

	- Every week, we'd schedule a developer's meeting, one in the early
	   hours for early UTC-ers, and another for late UTC-ers that would
           be determine whether or not it's a good idea to release a micro
	   version release. It'd take about 2 days' time afterward to see if
	   can agree to it and set goals for the next micro version as well
	   revise the minor version's goals.

       - Towards the close of the month, given that a minor release hasn't
	  been released, another meeting (can be done in the same time) could
	  be held (this one over the mailing list if easier) to determine a
	  minor release should be sent out.

      - The same for minor release applies to major versions, only that
	 this occurs every 2 months, and supersedes all potential meetings that
	 happen to fall within that week. The superseding is done in the sense
	 that the major version becomes the top priority, the minor the second 
	 priority, and the micro version being delayed if possible.

After a version version hits XX.8.5,  it's possible for us to move on to 
the next major release. Although this will leave XX.8.5 undone, development 
will continue on XX.8.5+ until it reaches XX.9.9 or when bugs reports, 
issues and other user requests to that major line have fell off.

I felt that this may be needed as we progress to define the such. This 
content should be on the Wiki, on its own and preferably link back to the 
link referring to this e-mail in the Launchpad archives. Thanks :D
-- 
Jacky Alcine <http://www.jackyalcine.co.cc>

Attachment: signature.asc
Description: This is a digitally signed message part.