<commit_before># Releasing Debezium

The Debezium project uses Maven for its build system, relying up on the _release_ plugin to most of the work.

The release process is automated by means of a parameterized [Jenkins job](https://github.com/debezium/debezium/blob/master/jenkins-jobs/release.yaml),
that takes the required information as an input (release version etc.)
and performs most of the required tasks.
Refer to [Automated Release](#automated-release) below for the details.

The following describes the individual steps of the release process,
which may be useful for updating the automated pipeline or in case a manual release is necessary.

## Configure Debezium versions in Jira

Start off from the [__Releases__](https://issues.redhat.com/projects/DBZ?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=released-unreleased)
page of the Debezium Jira project.

First, rename the current version (e.g. `1.7-next`) to the new version that
will be released (e.g. `1.7.0.Beta1`). All issues previously assigned to the old
_next_ version are now set to the version of the release.  
Then create a new `next` version, e.g. `1.7-next`.

## Verify Jira issues

All issues planned for this release must be resolved.
If not, they have to either be re-planned to another release or rejected.
Use JQL query to find offending issues
```
project=DBZ AND fixVersion=<VERSION> AND status NOT IN ('Resolved', 'Closed')
```

or navigate to the specific release on the [_Releases_](https://issues.redhat.com/projects/DBZ?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=released-unreleased)
page. 

Also make sure that each issue is assigned to a component ("mysql-connector" etc.).

## Update the changelog and breaking changes

Create two branches for pull requests to add changelogs (and release announcement) for this
main repository and the [`debezium.github.io` repository](https://github.com/debezium/debezium.github.io).
The change log should be updated with all relevant info on new features, bug fixes and breaking changes and
can be generated with the `Release Notes` tool in JIRA on the version's detail page.

* https://github.com/debezium/debezium/blob/master/CHANGELOG.md
* https://github.com/debezium/debezium.github.io/blob/develop/_data/releases/1.7/1.7.0.Beta1.yml
* https://github.com/debezium/debezium.github.io/blob/develop/releases/1.7/release-notes.asciidoc
* https://github.com/debezium/debezium.github.io/blob/develop/_data/releases/1.7/series.yml

JIRA issues that break backwards compatability for existing consumers, should be marked with the "add-to-upgrade-guide" label.
Search for them using [this query](https://issues.jboss.org/issues/?jql=labels%20%3D%20add-to-upgrade-guide) and describe the
implications and required steps for upgrading in the changelog on the website.

## Update antora.yml and series.yml

The `antora.yml` file in the `master` branch always used the version _master_.
During the release process, this file's `version` attribute should be changed to reference the correct major/minor version number.
There are other Asciidoc variables defined here that should be reviewed and modified as needed.

As an example, when releasing version `2.1`, the `antora.yml` file should change from:
```
version: 'master'
```
to
```
version: '2.1'
```

`series.yml` holds metadata for the `Tested Versions` section on the Debezium [Releases](https://debezium.io/releases/)
site and should be updated when dependencies were updated with the new release.


# Manual Release

You can skip this section to [__Automated Release__](#automated-release) when
using the Jenkins CI/CD Release pipeline for the rest of the release process.

## Start with the correct branch

Make sure that you are on the correct branch that is to be released, and that your local Git repository has all of the most recent commits. For example, to release from the `master` branch on the remote repository named `upstream`:

    $ git checkout master
    $ git pull upstream master

Then make sure that you have no local uncommitted changes:

    $ git status

This should report:

    On branch master
    Your branch is up-to-date with 'upstream/master'.
    nothing to commit, working directory clean

Only if this is the case can you proceed with the release.

## Rebase and merge development docs branch

The documentation of the current development version is published from the `development_docs` branch,
which always is based off of the latest development release tag.

The branch may contain critical documentation updates for the development release documentation,
which couldn't wait until the next release.
In this case rebase the branch to the current master and merge it:

    $ git checkout development_docs
    $ git rebase master
    $ git checkout master
    $ git merge development_docs

## Update versions and tag

Once the codebase is in a state that is ready to be released, use the following command to automatically update the POM to use the release number, commit the changes to your local Git repository, tag that commit, and then update the POM to use snapshot versions and commit to your local Git repository:

    $ mvn release:clean release:prepare

This will prompt for several inputs:

* The release version for each of the modules; answer each with the _major.minor.patch_ version number, such as `0.2.0`.
* The SCM release tag or label; answer with `v<releaseVersion>`, or `v0.2.0`.
* The new development version for each of the modules; answer each with the next _major.minor_ snapshot version, such as `0.3-SNAPSHOT`.

The build then proceeds to:<commit_msg>DBZ-3918 Removing reference to development_docs branch<commit_after># Releasing Debezium

The Debezium project uses Maven for its build system, relying up on the _release_ plugin to most of the work.

The release process is automated by means of a parameterized [Jenkins job](https://github.com/debezium/debezium/blob/master/jenkins-jobs/release.yaml),
that takes the required information as an input (release version etc.)
and performs most of the required tasks.
Refer to [Automated Release](#automated-release) below for the details.

The following describes the individual steps of the release process,
which may be useful for updating the automated pipeline or in case a manual release is necessary.

## Configure Debezium versions in Jira

Start off from the [__Releases__](https://issues.redhat.com/projects/DBZ?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=released-unreleased)
page of the Debezium Jira project.

First, rename the current version (e.g. `1.7-next`) to the new version that
will be released (e.g. `1.7.0.Beta1`). All issues previously assigned to the old
_next_ version are now set to the version of the release.  
Then create a new `next` version, e.g. `1.7-next`.

## Verify Jira issues

All issues planned for this release must be resolved.
If not, they have to either be re-planned to another release or rejected.
Use JQL query to find offending issues
```
project=DBZ AND fixVersion=<VERSION> AND status NOT IN ('Resolved', 'Closed')
```

or navigate to the specific release on the [_Releases_](https://issues.redhat.com/projects/DBZ?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=released-unreleased)
page. 

Also make sure that each issue is assigned to a component ("mysql-connector" etc.).

## Update the changelog and breaking changes

Create two branches for pull requests to add changelogs (and release announcement) for this
main repository and the [`debezium.github.io` repository](https://github.com/debezium/debezium.github.io).
The change log should be updated with all relevant info on new features, bug fixes and breaking changes and
can be generated with the `Release Notes` tool in JIRA on the version's detail page.

* https://github.com/debezium/debezium/blob/master/CHANGELOG.md
* https://github.com/debezium/debezium.github.io/blob/develop/_data/releases/1.7/1.7.0.Beta1.yml
* https://github.com/debezium/debezium.github.io/blob/develop/releases/1.7/release-notes.asciidoc
* https://github.com/debezium/debezium.github.io/blob/develop/_data/releases/1.7/series.yml

JIRA issues that break backwards compatability for existing consumers, should be marked with the "add-to-upgrade-guide" label.
Search for them using [this query](https://issues.jboss.org/issues/?jql=labels%20%3D%20add-to-upgrade-guide) and describe the
implications and required steps for upgrading in the changelog on the website.

## Update antora.yml and series.yml

The `antora.yml` file in the `master` branch always used the version _master_.
During the release process, this file's `version` attribute should be changed to reference the correct major/minor version number.
There are other Asciidoc variables defined here that should be reviewed and modified as needed.

As an example, when releasing version `2.1`, the `antora.yml` file should change from:
```
version: 'master'
```
to
```
version: '2.1'
```

`series.yml` holds metadata for the `Tested Versions` section on the Debezium [Releases](https://debezium.io/releases/)
site and should be updated when dependencies were updated with the new release.


# Manual Release

You can skip this section to [__Automated Release__](#automated-release) when
using the Jenkins CI/CD Release pipeline for the rest of the release process.

## Start with the correct branch

Make sure that you are on the correct branch that is to be released, and that your local Git repository has all of the most recent commits. For example, to release from the `master` branch on the remote repository named `upstream`:

    $ git checkout master
    $ git pull upstream master

Then make sure that you have no local uncommitted changes:

    $ git status

This should report:

    On branch master
    Your branch is up-to-date with 'upstream/master'.
    nothing to commit, working directory clean

Only if this is the case can you proceed with the release.

## Update versions and tag

Once the codebase is in a state that is ready to be released, use the following command to automatically update the POM to use the release number, commit the changes to your local Git repository, tag that commit, and then update the POM to use snapshot versions and commit to your local Git repository:

    $ mvn release:clean release:prepare

This will prompt for several inputs:

* The release version for each of the modules; answer each with the _major.minor.patch_ version number, such as `0.2.0`.
* The SCM release tag or label; answer with `v<releaseVersion>`, or `v0.2.0`.
* The new development version for each of the modules; answer each with the next _major.minor_ snapshot version, such as `0.3-SNAPSHOT`.

The build then proceeds to:
{'fraction_non_alphanumeric': 0.07548393072149671, 'fraction_numerical': 0.007224228952486802, 'mean_word_length': 4.54312114989733, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 20, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, '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': '4641072', 'n_tokens_mistral': 3066, 'n_tokens_neox': 2967, 'n_words': 1366}