<commit_before>= Cutting a Release

:Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at. http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR  CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
:page-partial:


The release process consists of:

* the release manager cutting the release (documented below)
* Members of the Apache Isis PMC xref:comguide:ROOT:verifying-releases.adoc[verifying] and voting on the release
* the release manager performing post-release tasks, for either a xref:comguide:ROOT:post-release-successful.adoc[successful] or an xref:comguide:ROOT:post-release-unsuccessful.adoc[unsuccessful] vote.

Apache Isis itself is released in one go, everything is ultimately a child of `bom/pom.xml` (relative to the link:https://github.com/apache/isis[source code root]).
This section details the process for formally releasing this module.

The subsequent sections describe how other committers can xref:comguide:ROOT:verifying-releases.adoc[verify a release] and how the release manager can then perform xref:comguide:ROOT:post-release-successful.adoc[post-release] activities and set up for the next development iteration.

If you've not performed a release before, then note that there are some configuration xref:comguide:ROOT:release-process-prereqs.adoc[prerequisites] that must be configured first.
In particular, you'll need signed public/private keys, and the ASF Nexus staging repo inlocal `~/.m2/settings.xml` file.

These release notes using bash command line tools.
They should work on Linux and MacOS; for Windows, use mSysGit.


== Preparation

[IMPORTANT]
====
The release process should be performed on Java 11.
====

[IMPORTANT]
====
The deploy process requires `gpg` v2.1 or later.
====

=== Obtain Consensus

Before releasing the framework, ensure there is consensus on the xref:docs:support:mailing-list.adoc[dev mailing list] that this is the right time for a release.
The discussion should include confirming the version number to be used, and to confirm content.

These discussions should also confirm the version number of the module being released.
This should be in line with our xref:comguide:ROOT:policies/versioning-policy.adoc#semantic-versioning[semantic versioning policy].

Make sure you have a JIRA ticket open against which to perform all commits.
In most cases a JIRA ticket will have been created at the beginning of the previous release cycle.


=== Pull down code to release

Set the HEAD of your local git repo to the commit to be released.
This will usually be the tip of the origin's `master` branch:

[source,bash,subs="attributes+"]
----
git checkout master
git pull --ff-only
----


=== License headers

The Apache Release Audit Tool `RAT` (from the http://creadur.apache.org[Apache Creadur] project) checks for missing license header files.
The parent `pom.xml` of each releasable module specifies the RAT Maven plugin, with a number of custom exclusions.
<commit_msg>ISIS-2965: fix for release docs<commit_after>= Cutting a Release

:Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at. http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR  CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
:page-partial:


The release process consists of:

* the release manager cutting the release (documented below)
* Members of the Apache Isis PMC xref:comguide:ROOT:verifying-releases.adoc[verifying] and voting on the release
* the release manager performing post-release tasks, for either a xref:comguide:ROOT:post-release-successful.adoc[successful] or an xref:comguide:ROOT:post-release-unsuccessful.adoc[unsuccessful] vote.

Apache Isis itself is released in one go, everything is ultimately a child of `bom/pom.xml` (relative to the link:https://github.com/apache/isis[source code root]).
This section details the process for formally releasing this module.

The subsequent sections describe how other committers can xref:comguide:ROOT:verifying-releases.adoc[verify a release] and how the release manager can then perform xref:comguide:ROOT:post-release-successful.adoc[post-release] activities and set up for the next development iteration.

If you've not performed a release before, then note that there are some configuration xref:comguide:ROOT:release-process-prereqs.adoc[prerequisites] that must be configured first.
In particular, you'll need signed public/private keys, and the ASF Nexus staging repo inlocal `~/.m2/settings.xml` file.

These release notes using bash command line tools.
They should work on Linux and MacOS; for Windows, use mSysGit.


== Preparation

[IMPORTANT]
====
The release process should be performed on Java 11.
====

[IMPORTANT]
====
The deploy process has been tested only with `gpg` 2.0.x ; you may need to adjust if using a later version.
====

=== Obtain Consensus

Before releasing the framework, ensure there is consensus on the xref:docs:support:mailing-list.adoc[dev mailing list] that this is the right time for a release.
The discussion should include confirming the version number to be used, and to confirm content.

These discussions should also confirm the version number of the module being released.
This should be in line with our xref:comguide:ROOT:policies/versioning-policy.adoc#semantic-versioning[semantic versioning policy].

Make sure you have a JIRA ticket open against which to perform all commits.
In most cases a JIRA ticket will have been created at the beginning of the previous release cycle.


=== Pull down code to release

Set the HEAD of your local git repo to the commit to be released.
This will usually be the tip of the origin's `master` branch:

[source,bash,subs="attributes+"]
----
git checkout master
git pull --ff-only
----


=== License headers

The Apache Release Audit Tool `RAT` (from the http://creadur.apache.org[Apache Creadur] project) checks for missing license header files.
The parent `pom.xml` of each releasable module specifies the RAT Maven plugin, with a number of custom exclusions.

{'fraction_non_alphanumeric': 0.06635867282654347, 'fraction_numerical': 0.0030799384012319755, 'mean_word_length': 4.983249581239531, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 2, 'lorem ipsum': 0, 'www.': 2, 'xml': 6}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '16750', 'n_tokens_mistral': 1876, 'n_tokens_neox': 1801, 'n_words': 936}