SDSHOWTO:Release Guidelines
What the version numbers mean
SDS version numbers are made up of three different numbers: the major release number, the minor release number, and the point release number.
SDS 3.4.1, for example, has major release 3, minor release 4, and point release 1.
The major release number is only incremented when something fundamental about the SDS changes. For example, the number was incremented to 3 when the codebase was rewritten to use the Gavintech Framework. When the major release number changes, the minor and point release numbers are reset to zero.
The minor release number is incremented monthly with each new SDS release. During each minor release, many things can be changed about the SDS, including what data it stores and how pages are laid out. If new pages are needed, they are also added during a minor release. The goals for the minor release are decided upon 6 weeks before the release at an SDS Committee meeting. 1 week before the release, the code is opened up for SDS Committee testing. They test the new features before everyone gets access so that any last-minute changes can be fixed. After the SDS Committee starts testing, no further changes are made except where a problem is found. When a minor release is made, the point release number is reset to zero.
The point release number is incremented whenever problems are found in a minor SDS release. For example, if a security problem is found that must be fixed before the next minor release, it is fixed and then put live as a new point release.
When can changes happen?
Point releases (emergency)
Emergency point releases may only contain fixes to security problems and data integrity issues. For example, if a bug is deleting or corrupting data stored in the SDS, that should be fixed in an emergency point release.
Emergency point releases are put live as quickly as possible after they are discovered and fixed.
Point releases (standard)
Standard point releases may only contain fixes for major regressions from previous minor releases. If the fixes can wait for the next minor release, no point release will be issued. For example, if a page ceases to work at all because of changes made during a minor release, these can be fixed during a standard point release.
New features, page layout problems (unless extremely severe), changes in what data is stored by the SDS, new pages, and all other changes must wait for the next minor SDS release. There will be no exceptions made to this policy, as larger changes must be well tested by the SDS Committee (at BCS) or the Beta testing group (at SMUS) before release, necessitating a minor release.
Standard point releases are put live at maximum once per week (on Friday afternoons). No point releases will be issued during beta testing for the next SDS release. This schedule can only be overridden (in exceptional circumstances) by the head of SDS development at each school (Dewi at BCS, Rob at SMUS).
Minor releases
Minor releases contain larger changes than point releases. These may include changes to the data stored by the SDS, page layout changes, new pages, page repurposing, etc.
At BCS, changes included in a minor release must be requested before the SDS Committee meeting for that release, which is typically held 6 weeks before release. Requests filed after this deadline may be included in the release if the amount of work required to satisfy the request is small and the request is unanimously approved by the SDS Committee. At SMUS, there is no SDS Committee, so the MIS department prioritizes the changes.
Major releases
Major releases are typically attempted over the summer break. When something fundamental to the SDS changes, or a new section that is very large is added (such as merging the SDS and maintenance database, for example), a major release is necessary.
While the monthly release schedule is still followed, sometimes several monthly releases are necessary for a major release. In this case, the monthly releases that are part of the new major release are numbered starting at 100 minus the number of extra monthly releases necessary to accomplish the release. For example, if 3 months are required to do the major release, 2 additional months are necessary, so the version numbers would be 3.98.0 and 3.99.0 before the 4.0.0 release.
As a large amount of testing is required for a major release, the code is typically frozen for testing two weeks before the final release. During this time, only fixes to bugs found in testing may be applied.