There will be standard releases quarterly, some time within the months of: February, May, August and November. These releases will be the primary way bug fixes and new features are made available.

The following diagram illustrates the 3 monthly release cycle, and how the development is structured on a week by week basis. The diagram is explained in detail below.

This diagram illustrates the standard release cycle.

 

For first two months of quarterly release cycle

  • Changes (bug fixes and new features) will be developed from all sources, and integrated into the various code repositories using those code repositories code management processes. Generally this will consist of raising a pull request, having that pull request undergo code review, and then be merged into the appropriate branch of the code repository.
    • For bugs raised via the CWP service desk: Issues raised by agencies or their representatives via service desk are first vetted to ensure they are (a) correctly categorised as bugs, rather than feature requests or issues with documentation or training, and (b) apply to a specific release of supported code. The issues that meet those criteria are added to an internal bug tracking system specific to the software package in question, and are then fixed in rough order of reception. The bug raiser is then given a bug identifier for later reference, and a rough time estimate for resolution. For bugs that do not apply to open source modules with their own release system, they will be allocated “likely”, “contingent” or “unlikely” to be in the next release depending on length of bug queue, average bug resolution rate and time till freeze. For bugs that do apply to open source modules with their own release system they will just be allocated as “next possible release”.
    • For new features developed by (or under the control of) SilverStripe Platform: When adding additional features, the expected release that the feature will be included in will be discussed with the person requesting the feature - the nominated DIA representative in the case of features being developed as part of the co-funded development pool, the agency representative in the case of directly-funded development, or the internal sponsor in the case of SilverStripe-internal efforts. Where one is available, such as for ORB sponsored work, a work item identifier will also be provided.
    • For changes developed outside the control of SilverStripe Platform: Each open source module has some level of module-specific development procedure, which all changes will continue to follow. All fixes merged into the appropriate branch prior to freeze (see below) will be in next release, except if removed during security or stability reviews.

Two weeks before start of month of release

  • An email announcement will be sent to all instance managers that there is an upcoming freeze for release. This providers a reminder to instance managers who have organised external development of changes that the absolute last deadline for having those changes integrated into the next release is approaching.
  • Pull requests that reference a CWP bug identifier in their request message will be reviewed, and the individual that raised the pull request will be notified of the impending freeze.

Start of month of release

  • Any pending pull requests that reference a CWP bug or work item identifier will undergo a final review
  • Release will undergo code freeze - all source code repositories will have a version selected for integration into the release, and no more changes will go into release at this point.
    • For modules with their own release cycle, we will take most recent stable release.
    • For modules with no release cycle, the most recent possible version will be tested and tagged with a new version number
  • A list of changes introduced between previous release and the new version will be produced.
  • When that list of changes have infrastructural or procedural prerequisites, those prerequisites will be reviewed for readiness, and deployed if required using standard change management processes.
  • When that list of changes includes fixes in an open source module that were previously released in a CWP-specific module, the now redundant fix from the CWP-specific module will be removed.
  • When that list of changes includes non-trivial changes:
    • A pre-release announcement including the list of changes (referencing bug or work item identifiers when applicable) will be emailed to all Instance Managers
    • All changes will be checked to ensure they do not introduce security issues. Where a change does introduce a security issue it will either:
      • Be resolved, if that resolution is trivial and unlikely to introduce regressions
      • Be removed or disabled for the release
    • All changes will be checked to ensure they do not introduce significant regressions. Where a change does introduce a regression it will either:
      • Be fixed, if that fix is trivial and unlikely to introduce regressions
      • Be removed or disabled for the release
    • If a change is removed or disabled, in order to minimise breaking any previous commitments to agencies regarding the inclusion of the change in the release, the developer who originally raised the pull request will be contacted. The release will be delayed by up to one week to allow that developer to provide an acceptable fix.
    • The release will be committed to the version control system
    • The list of supported releases will be updated
    • A release announcement including the list of changes (referencing bug or work item identifiers when applicable) will be emailed to all Instance Managers and uploaded to the cwp.govt.nz website
  • When that list of changes includes only trivial changes:
    • A notice indicating that a release is being skipped due to lack of significant changes will be emailed to all Instance Managers,

Agency actions post release

Once a release has been announced, agencies should, for each instance under their control:

  • Review the list of changes provided as part of the release announcement, and determine if an upgrade is necessary.
  • Integrate the release into the instance’s codebase. See upgrading for instructions.
  • Test to ensure the upgrade has not caused regressions. Where agencies find bugs they feel are specific to the new release, or where an upgrade to a new point release causes a regression, they should raise a bug request as quickly as possible via the Service Desk
  • Release newly updated codebase via the agency’s release procedure. See deploying code for details on the tools CWP provides for managing releases.

Last modified: