-
Notifications
You must be signed in to change notification settings - Fork 5
Releasing Tests and TEAM Engine
Releases of new revisions of tests and TEAM Engine follow a time boxed model. There is one monthly release with new revisions of tests in beta and at the same time a release in production. The release should happen in the week 2 or 3 of the month. If there are any changes on a test, the test lead should have the test ready by the first week of the month, and inform before the deadline for that particular month. See Release-Schedule for the exact dates. If there are no updates on a particular test, no new releases of the test will be performed. The tests that are released in the production website are those that have been in beta and no issues were reported related to that particular beta release.
The test lead informs of a test release by posting an issue in the OGC release tracker. OGC staff associates a milestone (month) to the issue providing information about the month the issue will be released. For example, the test WMS 1.1 revision 1.10 was released in the beta release 2015-06
The test lead should prepare and inform about a new release of a test following the Release-Schedule. The process check list is as follows:
- The master branch should contain the latest "stable" version. Make sure all verified pull requests are merged.
- Make sure it builds properly running
mvn clean install site -Pintegration-tests,docker. - Test locally the master branch with the reference implementation, if there is one. If there is none, any other implementation can also be used for a local test.
- If it is OK, continue, if not create or update an issue, in the issue tracker of that test.
- Review closed issues to be included in the release.
- Update title if appropriate.
- Tag, if they are not tagged with the milestone number.
- Update release notes, usually the file is at
src/site/asciidoc/changelog.adoc.- Add a new title for the revision, if there is not one already.
- Copy the issues to be included in the release, link and title.
- Add any other highlights.
- Create a new issue in the OGC release tracker and set label
approved-by-test-lead.- Write a title for the issue. It should contain: [Abbreviation] [version] revision [revision] in Beta. For example: WFS 1.1 revision 1.23 in Beta. It should always be in Beta. OGC staff will create the issue related to making the releases in the production, official web site.
- In the OGC release tracker assign the issue to a milestone.
- Do the release. Process involves creating a revision based on the pom.xml version, updating the GitHub page, tag, and updating the revision on the pom for the next release.
- Check if Maven configuration has been updated: How to create Releases with Maven.
- Create release with Jenkins.
- Close milestone in the ETS issue tracker.
- Set label
ready-for-installation.
- Install new releases on target environment.
- See How to update Production and Beta environments for further instructions.
- Execute testing of updated environment.
- Close issues and milestone in OGC release tracker.
- Announce the new release to CITE forum and CITE SC lists.
- Review which tests were in beta and can be moved to production. If no issues were reported in the forum, the tests can go to production at the proposed schedule.
- Create revision 1.0 of all test suites which are moved to Production for the first time.
- Proceed same steps as documented in previous chapter
Beta.- Install newly created revisions 1.0 on Production and Beta.
- Revisions of TEAM Engine will be treated in the same way as the tests are treated.
- TEAM Engine releases which are moved to Production are marked as releases in GitHub (e.g. https://github.com/opengeospatial/teamengine/releases/tag/5.4).
- Updates of Production environment shall be announced one week prior via mailing list (cite-forum).
- After the maintenance is done, a following email is sent confirming that maintenance is complete and TEAM Engine is back to normal.