db-jdo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jdo Wiki] Update of "ReleaseNomenclature" by BrianTopping
Date Wed, 06 Apr 2005 20:55:55 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jdo Wiki" for change notification.

The following page has been changed by BrianTopping:

New page:
Have you ever stumbled across a really nice looking project, downloaded and installed the
binaries that were labelled "RC1" and got to work on integrating it in your application, only
to find that "RC2" came out two weeks later with a host of feature changes, including some
new ones and changes to the interfaces that you rely on?  It's very frustrating for early
adopters, and this has translated into less aggressive adoption of open source by larger customers
because everyone is racing to have their code considered "release quality", often without
putting in the effort to actually deliver that quality.

The goal of a documented release nomenclature is that the users of your project can intelligently
choose a version at a glance, and know what they are getting in to when they do so.  As in
life, this is all about managing expectations.  Exceeding expectations always leads to happy

So without further ado, here is a proposed release nomenclatire for the Apache JDO project:

=== Stable Releases ===

Stable releases are numbered in the form of "x.y.z", where:

* ''x'' is the major version number of the library.  This number is incremented when there
are major changes to the underlying architecture or might be tied to the version of the specification
that it is tied to, as in our case.

* ''y'' is the minor version number, and indicates new features and/or changes significant
enough to affect compatibility with existing code.

* ''z'' indicates a bugfix release.  No changes to features or reduced compatibility are indicated
by such a release.

=== Unstable and Prerelease ===

* ''SNAPSHOT'' indicates that the code you are working with is whatever happened to be in
the source repository when the snapshot was made.  If the snapshot was made by an automated
tool in a nightly process, you may be wise to check the results of the associated unit tests.
 If you are concerned about functionality that you rely on, you might consider finding the
names of the unit test that most closely matches your code, and writing and contributing tests
if you cannot find them.  In doing so, you can not only check that a SNAPSHOT is suitable
for you at a glance, but you tend to assert with interested developers that you are interested
in the code working a certain way.  For projects such as JDO, the unit tests are generally
of the form of the TCK, in which case it is not practical to update the unit tests without
also updating the specification itself.  But your involvement there is encouraged as well!

* ''d'' or ''development'' releases are compilations that have been made of works in progress,
but at select points where developers may have felt that the code was at a very natural point
for people to work with it.  Contrasted with an automatic snapshot, a development release
is timed to coincide with the entire team at a point between tasks, affording maximum functionality
to outside users.

* ''a'' or ''alpha'' indicates that the software is feature complete with no catastrophic
bugs, but that the software may have bugs that in rare cases could be severe enough that unknown
bugs could cause unexpected data loss.  Projects with a strict release process generally implement
peer-review change control at this point, ensuring that changes that are made do not introduce
new functionality and are strictly tied to a documented bug.  By doing this, users are assured
that the number of bugs in the code is decreasing as the risk from new bugs in code with new
features are eliminated.  This will not stop developers from wanting to check in their changes
for new features in the next release, so a branch is created for this code, named for the
release that it will become, allowing developers to continue to work on HEAD if they choose.

* ''b'' or ''beta'' code has a quality level of "no known bugs that are not deferred".  This
means that if there are bugs (and there always are), they must be marked so as to defer them
to the next release or they must be fixed before another release can happen.  In doing so,
users can understand what to expect from a final release and a time window exists for them
to raise whatever objections they might have to the decisions that were made regarding code
that they are personally interested in.  

* ''rc'' or ''release candidate'' is the name that was traditionally given to code that was
packaged as if it were going to the printers, with tens of thousands of copies prepared to
be printed.  Dozens of people were required to do this in larger shops such as Apple (where
yours truly worked for some time), and decisions about change to a rc build were very lengthy
and agonizing for all involved.  

* In the age of printing on the internet, ''"Golden Master"'' and ''"Release To Manufacturing"''
builds are rarely seen, but are still very common in environments where large volumes of release
media are printed and sent into distribution channels.  These versions take on the appropriate
name indicated in a stable release.

View raw message