I thought it was time to codify our release protocol, it has changed a bit over the years but is now pretty consistent so I thought I would share it.<\/p>\n
We have a target of two major releases a year and two more interim releases between those. We aim to have a major release point in Q1 and then a further major release point in Q3 with an interim release point in Q2 and Q4.<\/p>\n
Interim releases usually consist of non-urgent bug fixes, small interface upgrades and corrections and not new functionality. Major release points will potentially have new functionality and new UI\/UX layouts, and perhaps entirely new sections and methodology.<\/p>\n
Interim releases will have a cut-off date for new tasks approximately 4 weeks before release date. This gives us four weeks to complete all the outstanding tasks then enter the testing phase and the subsequent iterations. A week before release we will produce some communications if we think there are changes that will impact our users or alter their workflows. We will offer all our users a chance to try out the release via our beta application. We will attempt to incorporate any minor feedback before the release date, or push back the release date by a maximum of 14 days in order to address the feedback correctly. If any major issues or feedback is received we may decide to draw back from the release, work on the new changes and rollup the interim release into the next major release.<\/p>\n
During this period we will collect and collate all bug reports and new feature requests and decide which are to be included in the interim release.
\nWork will begin immediately on making the required changes and updates to the beta version.<\/p>\n
No more new bug fixes or changes are accepted for this release (emergency bugs are handled differently and fall outside the\u00a0scope of planned upgrades).<\/p>\n
Work continues on completing tasks and testing<\/p>\n
Comms are sent and customers are invited to use the beta site and feedback with their experience and questions.<\/p>\n
Any feedback is incorporated and tested it possible<\/p>\n
Any tasks that have not been possible to complete are moved to the next release
\nFinal comms are produced if necessary and the release is scheduled for the end of the 12th week.<\/p>\n
Major releases are similar but the cut off date for new functionality is quicker as it will take longer to design, build and test fully. The cut off date is increased from 4 weeks before release to 8 weeks before release. This to allow for a longer period of testing by ourselves and the customers in order to enable us to capture and act on more feedback on potentially large changes.<\/p>\n
During this period we will collect and collate all bug reports and new feature requests and decide which are to be included in this release. This will usually entail at least one major change.<\/p>\n
No more new bug fixes or changes are accepted for this release (emergency bugs are handled differently and fall outside the\u00a0scope of planned upgrades).<\/p>\n
Work continues on completing tasks and testing<\/p>\n
Comms are sent and customers are invited to use the beta site and feedback with their experience and questions.<\/p>\n
Any feedback is incorporated and tested it possible<\/p>\n
Any tasks that have not been possible to complete are moved to the next release
\nFinal comms and support material is completed and distributed and the release is scheduled for the end of the 24th week.<\/p>\n
Normally we would expect to add a higher volume of small changes to the interim releases and less, but more impactful changes to the major release.<\/p>\n
This schedule can not always be followed and it may be necessary to only have one major release in a year and on occassion there are only interim releases as no major new functionality has been added.<\/p>\n
Releases are numbered using the regular convention;
\n1.2.3
\n^ ^ ^
\n| | |————— Minor revisions, spelling corrections etc
\n| |—————– Minor function changes or additions etc
\n|——————- Major function changes, UX\/UI changes etc<\/p>\n
An interim release would increment the last or second digit, a major release would increment the second or first digit. At the time of writing we were on TK v1.0.1 (after a major change from our old releases it was decided to reset the version numbers to 1.0.0). Our next release is scheduled for August and will be v1.1.0.<\/p>\n","protected":false},"excerpt":{"rendered":"
I thought it was time to codify our release protocol, it has changed a bit over the years but is now pretty consistent so I thought I would share it. We have a target of two major releases a year and two more interim releases between those. We aim to have a major release point […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[4,5],"tags":[],"class_list":["post-1967","post","type-post","status-publish","format-standard","hentry","category-policy-and-operations","category-technical-updates"],"jetpack_publicize_connections":[],"yoast_head":"\r\n