-
Notifications
You must be signed in to change notification settings - Fork 43
Software version and release scheme
Jolse Maginnis edited this page Apr 12, 2018
·
2 revisions
The following document is intended to outline several changes to the EQUELLA versioning convention as part of the platform’s recent transition to open source. These changes are intended to deliver new features/enhancements to EQUELLA users in a faster and more consistent manner.
- General Availability (GA) - All development work (bugs and features) since the previous GA is released at the end of a long development and testing cycle. Upgrading usually requires database migrations and configuration changes, so rolling back requires a restore from backup.
- Quality Assurance (QA) - Client-requested and important bug fixes are bundled up together with the occasional new feature. Often database migrations would be included, so sometimes rolling back would require a restore from backup.
- The intent of GA and QA releases were to be a single build at a specific development revision which were the only builds available to deploy. In practice, clients usually couldn’t wait for a new release to be ready so we often had to create untracked “plugin fixes” or special branches.
- Release “Streams” - Rather than having fixed release builds with large release cycle times, have two different streams of builds each of which will have an official current “latest” build at any given time.
- Beta - All new development ends up on this stream; the idea being that clients will install this on a test server and use it to access the latest features as early as possible, giving stakeholders the chance to provide feedback and report bugs before it becomes the stable branch.
- Will be guaranteed to be forward compatible unless a database migration is required
- Not suited for production deployments
- Should list any “breaking changes” - (e.g. language strings may change, CSS theme might need an overhaul, deprecated features may be removed)
- Release candidates - When the Beta stream contains all the intended features/fixes, the Beta stream versioning starts being labelled with "RC1" which signifies that it will be tested by the appropriate stakeholders and has the potential to become the next Stable release. If the stakeholders aren't happy with the build, appropriate changes are made and the version will be incremented to RC2 etc and tested again.
- Stable - After a “Release candidate” has been accepted by the Stakeholders, the Beta stream then becomes the new Stable release stream (e.g. 6.6-Beta becomes 6.6-Stable). At this point we make certain guarantees about what ends up on the stable stream:
- Only fixes which don’t migrate the database - code changes only
- Will be guaranteed to be forward and backward compatible (so that rolling back within a version (e.g., 6.5) can happen without the need for a backup)
- Enhancements can be added but they will be extremely low impact (e.g. better logging, for example)
- Typically fixes will only be added in response to a client request, provided an assessment determines it is low risk (the code remains stable)
- Major versions have their own stable stream (6.5-Stable, 6.6-Stable)
In order to enhance and support the new approach to EQUELLA versioning, additional functionality has been added to the platform:
- Version checking / automated change log - If a client finds a problem, they can use the version checking tool on the health tab to find out what’s been fixed in the latest official build of their stream. This page is generated automatically from the GitHub issues list and will only list the changes which aren’t in their current version already.
In order to have a high degree of confidence in any builds being released, it’s necessary to have the builds pass automated tests before they’re even created. This currently occurs but at a smaller scale - moving forward, automated testing will become much more widespread. Our full test suite is run before making any new build the “official latest”. As an open source platform, community testing will be the key mechanism for performing manual testing.
Please see below some scenarios intended to put these changes into context:
- Client just wants their current deployment to work as is but still request bug fixes:
- They stay on their versions stable stream (E.g. 6.5-Stable)
- If they need a bug fixed, report it and it will have a good chance of ending up on the Stable stream (pending risk assessment)
- Client has requested a new feature or there is a feature that they have a particular interest in (this is also applicable for sponsored development):
- Client should have a server setup on the “Beta” stream and upgrade it when the feature they need has become available
- Be aware of the “breaking changes” - contact us if there is any concern
- Test the feature and provide feedback / bug reports
- Report any regressions if found
- Client doesn’t have a particular vested interest in any particular feature but would just like to have “the latest stuff”:
- Setup a “Beta” stream server and test that their existing functionality works as expected
- Be aware of the “breaking changes” - contact us if there is any concerns
- Report any regressions if found
- Client wants “the latest stuff” but doesn’t participate in any of the beta version testing on a test server prior to the Stable release being available:
- Upgrade their prod server to the next stable release
- Report an issue when something doesn’t work
- Pending a risk assessment, if it’s an easy and safe fix, we will endeavour to release the fix to the Stable stream immediately