These instructions complement those from http://sling.apache.org/documentation/development/release-management.html, which are geared more towards bundle releases, while releasing the Launchpad is a bit more involved.

Prepare the Starter release

Since the Launchpad is a collection of bundles, it is required for each bundle included it in to be a release, rather than a SNAPSHOT. We currently have only releases in the starter, so this should not be an issue.

Create a new and noteworthy page

A new and noteworthy page outlines some of the significant changes done since the last release. The launchpad-comparator Java project allows generating a changelog between two versions of the Sling Starter and can be used to extract the new and noteworthy items. The README file from that project contains all the information needed to generate the changelog. You can generate the output as markdown and put it into GitHub comment to make share it with others (example). Since Sling 13, we also included this generated list of changes in the new and noteworthy page.

Additionally, we tag issues that we consider noteworthy with the label Sling-VERSION-Release-Notes. For instance, the query for the Sling 13 release notes is  project = SLING AND labels = Sling-13-ReleaseNotes ORDER BY updated DESC .

Example pages:

Update and release the "core" set of artifacts

Although the Sling Starter is composed of just one artifact, we aim to release at least the tests and the Maven archetypes at the same time. We release the tests to capture the state of how Sling worked for that certain release, and the archetypes to allow users to start using them with the latest Starter version from day one.

Currently we release the following artifacts:

After releasing the Sling Starter switch back to the new SNAPSHOT version of the Test Services and Integration Tests modules so future changes are automatically picked up. See https://github.com/apache/sling-org-apache-sling-starter/pull/431 for an example.

It is not recommended to group the Sling Starter itself and the other bundles in the same release vote. The Sling Docker images are automatically built on DockerHub when a release tag is created and it a bundle is missing since it is not yet released the build will fail and will need to be manually recovered. It is possible to trigger a new build later on by deleting the release tag and creating it again but it complicates the release process and is therefore not recommended.

Check archetype projects

After the release archetype projects should be checked if they are still compatible with the latest Sling release:

Deploy the new API docs

For each version we deploy the aggregated javadoc for for the Sling bundles contained in the launchpad. The javadoc  can be generated using the generate_javadoc_for_release.sh script. The script picks up artifacts from the Starter file, and manually adds others which we consider required, such as annotations. Any additional artifacts should be manually added to the script.

After generating the artifacts these should be copied in the sling-site repository, in branch asf-site under apidocs/sling${VERSION} and then referenced from:

  • the sidebar ( src/main/jbake/templates/menu.tpl )
  • the API docs page ( src/main/jbake/content/documentation/apidocs.md )

As the reference pages are built with JBake (in contrast to the javadoc itself) those need to be updated in branch master 

For Sling 11 the javadoc deployment has failed once with an error similar to "Argument list too long". However, a second build allowed the publish to continue and succeeded. The key is to not invoke Maven with the clean phase, as the progress would be wiped.

Update Sling Site

After the Sling Starter release, several places in the Sling Site need to be adjusted (see PRs #187 and #188 as example for Sling Starter 13):

Deploy the docker image on DockerHub

Since the Sling 8 release we also provide a docker image. As of the Sling Starter 13 release, the process is automated using GitHub Actions . Pushing a tag of the form org.apache.sling.starter-$VERSION  will result in a DockerHub tag of $VERSION  and also in the latest  tag being updated.

We moved away from DockerHub automated builds because they did not support multi-arch builds. This was disabled with INFRA-24458 - Getting issue details... STATUS .

Update local references to the old starter

A number of Sling modules on GitHub tree reference the Sling starter mostly for testing. These projects should be updated to either reference the latest release, if they use it for testing additional sets of bundles, or to the latest SNAPSHOT, if they are used to test the current launchpad, like launchpad/testing or launchpad/testing-war .

Update the Apache Sling Wikipedia page

The page is at https://en.wikipedia.org/wiki/Apache_Sling and we should update at least the latest released version and the corresponding release date.

Announce release

Apache Announcements mailing list

Send an email to users@sling.apache.org and announce@apache.org . For example, see [ANN] Apache Sling 12 released or [ANN] Apache Sling 13 Released

Note

When sending the announcement to announce@apache.org: You must send this email from your Apache email account, e.g. YOUR_APACHE_USERNAME@apache.org otherwise the email will bounce. And it may take a bit until the mail is actually send out due to list moderation.

Press release

The ASF Marketing and Publicity team can support drafting and publishing a press release. See Public Relations Services ; discussion can be started via email to markpub@ . We did a press release for Sling 13: https://news.apache.org/foundation/entry/the-apache-software-foundation-announces-apache-sling-13 

See also

  1. Launchpad 8 release tracking task: SLING-5095 - Getting issue details... STATUS
  2. dev@sling.apache.org: Sling 8 release checklist
  3. dev@sling.apache.org: Launchpad 7 release?
  4. Towards Sling 6
  5. dev@sling.apache.org: Sling 6 release plan


  • No labels