Skip to content

Releasing Tests to the OGC Testing Infrastructure

dstenger edited this page Apr 29, 2019 · 54 revisions

Summary of test releases in the OGC testing infrastructure

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

Test lead release checklist:

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:

Prepare release (for each test suite individually)

  • 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 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/markdown/relnotes.md.
    • 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 should containing: [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.

OGC Validation Tools Release Manager checklist:

Beta

Create release (for each test suite individually)

  • In the OGC release tracker assign the issue to a milestone.
  • Check that the issues and pull requests in the ETS issue tracker are properly written and associated to the correct milestone. Make sure issues are closed in the ETS issue tracker.
  • 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.
  • Close milestone in the ETS issue tracker.
  • Set label ready-for-installation.

Install and advertise releases (for all test suites together)

Production

  • Review which tests were in beta and can be moved to production. If no issues were reported in the forum then the test can go to production at the proposed schedule.

TEAM ENGINE

  • Revisions of TEAM Engine will be treated in the same way as the tests are treated.
You can’t perform that action at this time.