Opticks Versioning Scheme

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Opticks Versioning Scheme

Kip Streithorst
Administrator
Now that Opticks is open-source, the team has come to the realization
that we need to formalize our versioning scheme.  This is for a couple
of reasons:

1) It would allow users to determine if a release is production worthy
or not just be looking at the version #.
2) It would allow users to determine if two versions are binary
compatible without having to read some release notes somewhere.
3) It would clearly and concisely support multiple types of releases of
the software and support multiple lines of development, some binary
compatible and some not.

You will see the proposed versioning scheme below.  Please let us know
if you have any problems with the scheme or suggestions for the scheme.
I have also attached a small image which attempts to diagram some common
usages of the versioning scheme.

Thanks,
Kip


Opticks Version Scheme
-------------------
All releases of the Opticks application are one of the following types:
 - Nightly Release
 - Milestone Release
 - Release Candidate
 - Production Release

Please read the Definitions section below to determine the meaning and
use of each release type.  The following shows a typical Opticks
development lifecycle.  Throughout development, users or plug-in
developers can get nightly releases of the software.  Milestone releases
are made available at specific intervals during development to allow
users or plug-in developers to experiment and report bugs against a
specific milestone release instead of the unstable nightly releases.  A
release candiate is created at the end of development to allow the
Opticks team and the community to test the application to determine if
it is production worthy.  Release Candidates are created until a
production worthy version is found.  A production release is then
created allowing users to create production quality analysis products.

The versioning scheme defines which versions are binary compatible.  The
versioning scheme is composed of parts separated by a period (.).
Changes to only the third part indicate releases are binary compatible.
The following pairs are binary compatible: 4.1.0 and 4.1.4; 4.2.3 and
4.2.4; 4.3.0 and 4.3.1; 4.3.0M1 and 4.3.0M2; 4.3.2M1 and 4.3.2RC1;
4.2.2Nightly20080320 and 4.2.3RC1; 4.2.2Nightly20080320 and
4.2.3Nightly20080510.  The following pairs are binary incompatible:
4.1.0 and 4.3.0; 4.1.1 and 4.2.1; 4.1Nightly20080412 and
4.1Nightly20080413; 4.1M1 and 4.1M2.

Definitions
-----------
Nightly Release - This is a release of the Opticks application which is
performed automatically overnight.  The latest code of a trunk is used
for the nightly build.  These releases are marked "Not for Production"
and are minimally tested.  The word Nightly and the date of the nightly
in the format YYYYMMDD are appended to the next expected release number.
The following versions are examples of nightly releases:
4.1Nightly20080321, 4.1Nightly20081123, 4.2.0Nightly20090123,
4.3.2Nightly20100414.  

Milestone Release - This is a release of the Opticks application which
occurs during long breaks between production releases.  These releases
are marked "Not for Production" and are minimally tested.  These
releases allow end-users and plug-in developers to use and report bugs
on development work between production releases.  The letter M and an
incremeting number are appended to the next expected release version.
The milestone number starts at 1 for each unique version number. The
following versions are examples of milestone releases: 4.2M1, 4.2M2,
4.3M1, 4.4M1, 4.4M2, 4.2.2M1, 4.2.2M2, 4.3.1M1, and 4.4.5M1.  

Release Candidate - This is a release of the Opticks application which
occurs immediately before a production release.  This release is tested
to ensure the application is production quality.  If a release candidate
passes testing, a production release is created. No functional changes
will be integrated between the final release candidate and the
production release.  If a release candidate fails testing, a new release
candidate is created with fixes for any test failures.  RC and an
incrementing number are appended to the end of the next expected release
version.  The release candidate number starts at 1 for each unique
version number. The following versions are examples of release
candidates: 4.2.0RC1, 4.3.0RC1, 4.3.3RC1, 4.3.3RC2, 4.4.1RC1, and
4.4.2RC1.  

Production Release - This is a production release which has been fully
tested. It is used to create production quality analysis products.  The
following versions are examples of production releases: 4.1.0, 4.1.1,
4.1.2, 4.2.0, 4.2.1, 4.2.2, 4.3.0, and 4.3.1.



This message and any enclosures are intended only for the addressee.  Please  
notify the sender by email if you are not the intended recipient.  If you are  
not the intended recipient, you may not use, copy, disclose, or distribute this  
message or its contents or enclosures to any other person and any such actions  
may be unlawful.  Ball reserves the right to monitor and review all messages  
and enclosures sent to or from this email address.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

OpticksVersioningScheme.png (80K) Download Attachment