Release v3.1

[galtm]

Setting up the v3.1 release checklist while clarification ideas are on my mind from the v3.0 release.

Tip: Leave time for community feedback between the first notification and the release.

Three-part version numbers: In this checklist, num means the third part of a three-part version number. Be sure to replace num with whatever the third part should be, which depends on how many intermediate releases were made to capture a "notable change" as described in the release workflow.

TODOs

(based on Release Workflow)

1. Prepare the release

   • Draft a new release (v3.1.num) at Releases page. The draft will help you write the add-on description and the mailing list notification message. The heading and proposed Git tag should use a three-part version number.

   • Release 3.1.num to Oxygen add-on channel (Stable Release Candidate)

   • Test the add-on 3.1.num with Oxygen 26.1

     • All the 4 transformation scenarios should work. (Don't forget to test Run XSpec Test with XSLT, XQuery and Schematron.)
     • Schematron Unit Test and XQuery Unit Test templates are available in File > New dialog, under Framework templates > XSpec. These aren't the same as the templates under New Document in that same dialog.
     • Loading xspec.xpr should disable the add-on and enable its own framework.

   • Notify the xml-dev mailing list (xml-dev@lists.xml.org) of the upcoming v3.1.num release. Notable changes are taken from the highlights at the top of the release note draft.

   • Create a pull request replacing -SNAPSHOT with the number, num, in pom.xml and the Oxygen add-on. Merge it into master

2. Release it

   • Make sure 3.1.num has been deployed to Maven Central successfully (automated)
   • Publish the release at Releases page
   • Promote the release v3.1.num
     • xml.com, using form at https://www.xml.com/news/submit-news-item/
     • xml-dev mailing list, xml-dev@lists.xml.org
     • tweet
     • Write post on xspec.io

3. Update Wiki

   • Complete the documentation issues
   • Where early drafts of documentation mentioned the "Upcoming" 3.1 release, change the verbiage accordingly.

4. Create a pull request for the Oxygen XSpec Helper View

   • Create it

5. Prepare the next development

   • Close the milestone related to v3.1
   • Create the milestone for v3.2 (or v4.0 if anticipating a major release)

6. Start the next development

   • Create a pull request incrementing the version (to 3.2-SNAPSHOT or 4.0-SNAPSHOT depending on anticipated next release) of pom.xml and merge it into master. This step uses a two-part version number, not a three-part version number.

(If something critical is found, we will create a branch for the next 3.1.z-SNAPSHOT and work on it.)