wiki:ReleaseProcedure

Release Procedure

There are three levels for a release to traverse:

  1. Development

    New features and repairs are specified in tickets. The new work is committed to the repository in separate development branches by separate developers. Just prior to merging any new work into trunk, developers merge from trunk and run all unit tests and other tests to prove nothing is broken.
  1. Deployed for acceptance testing

    When developers are sure their work is suitable for acceptance testing they merge it with the tested code in the trunk of the repository.
  1. The Release Manager reviews the work, runs any special tests and if happy deploys the latest software to the staging server at https://ssds.climate.com.au/admin.

Software on the staging server will generally not match that on the production server. It will jump ahead as developers commit new work. See Life-cycle decorators below.

  1. Deployment for production

    When acceptance-tested on the staging server, the new work is tagged by the Release Manager for deployment to the production server at https://ssds.sharedsds.com/admin/

Version numbering x.x.x

  • In the first position is the major release indicator.
    • 0.x.x means the system is at the prototype or developmental stage and not mature enough or sufficiently feature-complete for public production.
    • 1.0.0. will be assigned when stakeholders consider it is sufficiently fit for purpose. This may not be fully feature-complete but at least version 1.x.x will be considered stable for those features which are offered.
    • Version 2.0.0 and subsequent increments in the first position will each be a major change. It will be used to introduce a feature set or behaviour which would not have been possible in the previous major version. It will probably break API backwards compatibility.
  • In the second position, the numeral, 0.0.0 represents a milestone release. It will signify completion of a set of one or more new features which have been adequately documented for users. See Life-cycle below. Features which would break backwards compatibility will be introduced as new features alongside the old ones which will remain. See also, Deprecation below.
  • The third number 0.0.0 will be incremented to signify sets of one or more repairs to existing features or introduction of minor "missing" features.
  • The fourth part of the version number is a life-cycle "decorator" such as 0.0.0b or 0.0.0rc2

Life-cycle decorators

Once we reach version 1.0.0, there will be a typical software life-cycle traversed for all milestone (new feature) releases. The new version will have a decorator appended to the revision number:

  • 'a' means alpha -- which is for first impressions by one or two very friendly users
  • 'b' means beta -- which incorporates any changes suggested by the alpha user(s) and is for testing by just a few more friendly pioneers
  • 'rc1' -- the first Release Candidate. It embodies a feature-freeze which means no substantive changes other than repairs from the beta testing phase. It should be introduced for wider testing by more users
  • 'rc2' etc -- repaired version of rc1 etc
  • undecorated -- means final release as version x.x.0 for production use.

Deprecation

Release notes from time to time will indicate that a new feature has been introduced to replace an old feature. The old feature is thereby deprecated and should not be used in new software.

Deprecated features will not be removed until the next major release.

Last modified 3 years ago Last modified on Nov 17, 2015 4:42:47 PM