-
Notifications
You must be signed in to change notification settings - Fork 357
Jersey EE 8, 9, and 10 release process
Goal: Use existing Jenkins job to publish project artifacts to Jakarta OSSRH.
It is essential before release to check that Jenkins CI builds are passed OK (with tests). After that check the public issues tracker to verify all issues and/or PRs associated (the milestone mark is properly set) with the current release version are closed/resolved.
There are 2 release jobs to release Jakarta EE 8/9 Jersey and Jakarta EE 10 Jersey. The used JDK and several related minor differences give the difference between jobs.
The release job for the Jersey EE 10 is located at the Jakarta EE10 Release Jenkins' tab (or All view). Input parameters are similar to the EE 8/9 release job.
The release job is located at the Release Jenkins' tab (or All view). It consumes 5 parameters:
- RELEASE_VERSION (string) put release version here - like 2.29
- NEXT_VERSION (string) new development version - with SNAPSHOT - to be put in next (after release) pom.xml files like 2.30-SNAPSHOT
- BRANCH (drop down) - branch from which release is being done. Usually master but for some reason may be any other
- DRY_RUN (checkbox) - if checked - nothing is committed/published, after build all changes are rolled back
- OVERWRITE (checkbox) - if checked - overwrites existing GitHub tags and branches (valid for open staging repositories as well)
The job runs with reduced output, so the log is almost empty. It takes approximately 1 hour for the job's run to finish. When finished (and if no DRY_RUN is checked) the job does a few things:
- Git:
- Creates a branch which is named as <RELEASE_VERSION>-BRANCH,
- Creates a tag which is named as <RELEASE_VERSION>,
- pom files in the <RELEASE_VERSION>-BRANCH are increased to the version from NEXT_VERSION
- Maven staging:
- publishes artifacts to related staging
- staging gets closed (not released to central) after the job is over
After build artifacts are in Maven's staging (not in Central), so there are a few things that are required to be completed before releasing to Central:
- the second thing to do is to publish bundles and user guide besides released artifacts. There are three jobs for that Jersey-apidocs_bundle_release, Jersey-examples_bundle_release, and Jersey-docbook-release. All accept only the VERSION parameter. One job shall be run after another. The order of jobs' runs is not important.
After those steps are accomplished everything - Jersey artifacts, bundles, and user guide are in Maven staging.
As soon as every published artifact is ready to be promoted to central we can proceed with the final steps to move everything to Central. The first thing is to find out what to publish. Run list-closed-stagings job and take a look into its archived artifact which is called closed_stagings.txt. It is a text file that contains only Jersey's stagings ready to be promoted to Central. When this is identified, run job release-staging-to-central. This requires two parameters (which shall be taken from closed_stagings.txt file):
- STAGING_REPO_ID - id of a repository to be promoted (or comma separated list of IDs like
orgglassfishjersey-1222,orgglassfishjersey-1218,orgglassfishjersey-1219,orgglassfishjersey-1220) - STAGING_DESC - description of a repository to be promoted - single for all promoted stagings - usually group id and version (
org.glassfish.jersey:3.1.5)
Please note, that after jobs are finished (OK) there is some delay (usually for 1 - 1.5 hours) for artifacts and bundles to appear in Central. So, just wait, do not re-run the job because it will cause failures of the job itself (promoted artifacts won't be affected).
After artifacts are visible in the central it is required to update release notes at GitHub by the job Jersey_publish_release_notes and update the site's documentation by the job populate_documentation and finally update the site's project info by the job release_project_info. Also, it's preferable to update the latest release version at the gh-pages branch (shall be done manually).
Create a PR with the job create_release_pr from the <RELEASE_VERSION>-BRANCH into the origin branch (like 2.x, 3.0, 3.1 - depending on the version released). Merge (not squash not rebase but purely merge - this keeps the release tag properly referred to in the origin branch) the PR into the origin branch and delete the <RELEASE_VERSION>-BRANCH branch from the GitHub.
Due to the latest events with artifacts indexing (properly updating the index.html files), it's preferable to make sure all artifacts are really visible in the Central - run the job validate_release_in_central and check the generated SUMMARY.TXT file to really see all artifacts are properly visible in the Central.
After all those steps are successfully done the Jersey's release can be counted as done. Take a look into Central http://central.maven.org/maven2/org/glassfish/jersey/ to check if everything is on the place (after described delay). Shall be visible and ready to use by community.