Title: Release Management

*This is the release process for Apache Felix, based on Apache Maven [process](https://maven.apache.org/developers/release/releasing.html)

## Basics

Apache Felix artifacts are distributed in two channels: The Maven Repository and the Apache
distribution channels.

The basic steps for releasing are:

* [Release the module with the Maven Release plugin deploying to the Nexus Staging repository](#staging-the-release-candidates)
* Check the artifacts
* [Call for vote](#starting-the-vote)
* [Publish the release candidate](#promoting-the-release):
    * Publish the staged artifacts from Nexus Staging
    * `svn add` the artifacts to the `dist` Subversion repository and `svn rm` the artifacts from the previous release
* [Announce the release](#create-an-announcement)

<div class="note">
The Apache Felix PMC appreciates all committers playing release manager for the projects they
maintain. Due to restrictions imposed on us, only members of the PMC are actually able to
commit the releases to the distribution repository (See <a href="#promoting-the-release">Publish the release candidate</a>).
In this case please ask a member of the PMC to actually publish the release artifacts. Thanks.
</div>

## Prerequisites

To prepare or perform a release you *MUST BE* at least an Apache Felix Committer.

* each and every release must be [SIGNED](https://www.apache.org/dev/release-signing.html); your public key should be added to [https://www.apache.org/dist/felix/KEYS] (see *Appendix A*)
* your public key should also be cross-signed by other Apache committers (not required, but suggested)
* make sure you have all Apache servers defined in your [settings.xml](https://maven.apache.org/developers/committer-settings.html)
* use Maven 3.5.0 (or higher) 

*Note*: Listing the Apache servers in the `settings.xml` file also requires adding the password to that file. Starting with Maven 2.1 this password may be encrypted and needs not be give in plaintext. Please refer to [Password Encryption](https://maven.apache.org/guides/mini/guide-encryption.html) for more information.

In the past we staged release candidates on our local machines using a semi-manual process. Now that we inherit from the Apache parent POM version 5, a repository manager will automatically handle staging for you. This means you now only need to specify your GPG passphrase in the release profile of your `$\{user.home\}/.m2/settings.xml`:

    :::xml
    <settings>
      ...
      <profiles>
        <profile>
          <id>release</id>
          <properties>
            <gpg.passphrase> <!-- YOUR KEY PASSPHRASE --> </gpg.passphrase>
          </properties>
        </profile>
      </profiles>
      ...
    </settings>


Everything else has been configured in the latest Felix parent POM:

    :::xml
    <parent>
      <groupId>org.apache.felix</groupId>
      <artifactId>felix-parent</artifactId>
      <version>6</version>
      <relativePath>../pom/pom.xml</relativePath>
    </parent>


## Staging the Release Candidates

First prepare your POMs for release:

1. Make sure you have correct NOTICE, [DEPENDENCIES]({{ refs.dependencies-file-template.path }}), and LICENSE files. Remember to update the copyright year.
1. Make sure you have an updated change log file, typically in `doc/changelog.txt` but in the project root is also acceptable.
1. Make sure there are no snapshots in the POMs to be released
1. Check that your POMs will not lose content when they are rewritten during the release process
    * `mvn release:prepare -DdryRun=true`
    * diff the original `pom.xml` with the one called `pom.xml.tag` to see if the license or any other info has been removed. This has been known to happen if the starting `<project>` tag is not on a single line. The only things that should be different between these files are the `<version>` and `<scm>` elements. If there are any other changes, you must fix the original `pom.xml` file and commit before proceeding with the release
1. Publish a snapshot. This is useful for existing builds that still depend on a snapshot version of this artifact. It means that the snapshot they will be getting is effectively the same as
the released version.
    <div class="codehilite"><code>$ mvn deploy   
    ...  
    [INFO] [deploy:deploy]  
    [INFO] Retrieving previous build number from apache.snapshots.https  
    ...</code></div>
    * if you experience an error during deployment like a HTTP 401 check your settings for the required server entries as outlined in the *Prerequisites*
    * be sure that the generated artifacts respect the Apache release [rules](https://www.apache.org/dev/release.html): NOTICE and LICENSE files should be present in the META-INF directory within the jar. For -sources artifacts, be sure that your POM does not use the maven-source-plugin:2.0.3 which is broken. The recommended version at this time is 2.0.4
    * you should verify the deployment under the [snapshot](https://repository.apache.org/content/groups/snapshots/org/apache/felix) repository on Apache
1. Prepare the release
    <div class="codehilite"><code>$ mvn release:clean    
    $ mvn release:prepare</code></div>
    * preparing the release will create the new tag in git, automatically checking in on your behalf
1. Stage the release for a vote
    <div class="codehilite"><code>$ mvn release:perform</code></div>
    * the release will automatically be inserted into a temporary staging repository for you, see the Nexus [staging documentation](https://www.sonatype.com/books/nexus-book/reference/staging.html) for full details
    * you can continue to use `mvn release:prepare` and `mvn release:perform` on other sub-projects as necessary on the same machine and they will be combined in the same staging repository - this is useful when making a release of the Felix framework and its associated bundles.
1. Close the staging repository
    * login to [https://repository.apache.org](https://repository.apache.org) using your Apache SVN credentials. Click on *Staging* on the left. Then click on *org.apache.felix* in the list of repositories. In the panel below you should see an open repository that is linked to your username and IP. Right click on this repository and select *Close*. This will close the repository from future deployments and make it available for others to view. If you are staging multiple releases together, skip this step until you have staged everything
1. Verify the staged artifacts
    * if you click on your repository, a tree view will appear below. You can then browse the contents to ensure the artifacts are as you expect them. Pay particular attention to the existence of \*.asc (signature) files. If you don't like the content of the repository, right click your repository and choose *Drop*. You can then rollback your release (see *Canceling the Release*) and repeat the process
    * note the staging repository URL (especially the number at the end of the URL) you will need this in your vote email.


## Starting the Vote

Propose a vote on the dev list with the closed issues, the issues left, and the staging repository - for example:

    :::text
    To: "Felix Developers List" <dev@felix.apache.org>
    Subject: [VOTE] Release Felix XXX version Y.Z
    
    Hi,
    
    We solved N issues in this release:
    https://issues.apache.org/jira/...
    
    There are still some outstanding issues:
    https://issues.apache.org/jira/...
    
    Staging repository:
    https://repository.apache.org/content/repositories/orgapachefelix-[YOUR REPOSITORY ID]/
    
    You can use this UNIX script to download the release and verify the signatures:
    https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
    
    Usage:
    sh check_staged_release.sh [YOUR REPOSITORY ID] /tmp/felix-staging
    
    Please vote to approve this release:
    
    [ ] +1 Approve the release
    [ ] -1 Veto the release (please provide specific comments)
    
    This vote will be open for 72 hours.

To get the JIRA release notes link, browse to the FELIX [JIRA](https://issues.apache.org/jira/browse/FELIX) page, select [Release Notes|https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12310100] and choose the relevant sub-project release and format (HTML)

To get the list of issues left in JIRA, select the [Open Issues](https://issues.apache.org/jira/browse/FELIX?report=com.atlassian.jira.plugin.system.project:openissues-panel) tab on the main FELIX page, and select the relevant sub-project.

## Wait for the Results

From [Votes on Package Releases](https://www.apache.org/foundation/voting.html):

> Votes on whether a package is ready to be released follow a format similar to majority approval  -- except that the decision is officially determined solely by whether at least three +1 votes were registered. Releases may not be vetoed. Generally the community will table the vote to release if anyone identifies serious problems, but in most cases the ultimate decision, once three or more positive votes have been garnered, lies with the individual serving as release manager. The specifics of the process may vary from project to project, but the 'minimum of three +1 votes' rule is universal.

The list of binding voters is available at [{{ refs.project-management-committee-pmc.headers.title }}]({{ refs.project-management-committee-pmc.path }})

If the vote is successful, post the result to the dev list - for example:

    :::text
    To: "Felix Developers List" <dev@felix.apache.org>
    Subject: [RESULT] [VOTE] Release Felix XXX version Y.Z
    
    Hi,
    
    The vote has passed with the following result :
    
      +1 (binding): <<list of names>>
      +1 (non binding): <<list of names>>
    
    I will copy this release to the Felix dist directory and
    promote the artifacts to the central Maven repository.

If the vote is unsuccessful, you need to fix the issues and restart the process - see *Canceling the Release*.
If the vote is successful, you need to promote and distribute the release - see *Promoting the Release*.

## Canceling the Release

If the vote fails, or you decide to redo the release:

1. remove the release tag from Subversion (`svn rm ...`)
1. login to [https://repository.apache.org](https://repository.apache.org) using your Apache SVN credentials. Click on *Staging* on the left. Then click on *org.apache.felix* in the list of repositories. In the panel below you should see a closed repository that is linked to your username and IP (if it's not yet closed you need to right click and select *Close*). Right click on this repository and select *Drop*.
1. rollback the version in the `pom.xml` and commit any fixes you need to make

<div class="info" markdown="1">
The release manager is free to either reuse the same version when proposing a new release for vote (for example 2.1.2 after a failed 2.1.2 release attempt), or choose a different number (for example 2.1.4 after a failed 2.1.2 attempt).  (cf. vote on 02/14/11).
</div>


## Promoting the Release

If the vote passes:

* [Upload the Artifacts](#upload-the-artifacts)
* [Release to the Maven Repository](#release-to-the-maven-repository)
* [Release Bundles to the OBR](#release-bundle-to-the-obr)
* [Update the Site](#update-the-site)

### Upload the Artifacts

<div class="note">
If you are not a member of the Apache Felix PMC you might have to ask a member of
the PMC to execute this step.
</div>

<div class="note">
It is recommended to use the check_staged_release.sh script to download your release prior to releasing the staging repository. This will make the task of uploading the release to the Felix releases repository easier.
</div>

We use the distribution mechanism as described in [How do I upload a release (newer way)?](https://www.apache.org/dev/release.html#upload-ci)

1. Check out the [Felix releases repository](https://dist.apache.org/repos/dist/release/felix);
1. `svn add` the artifacts to your checkout;
1. `svn rm` the artifacts from the previous release from your checkout. This
will remove the artifacts from the main distribution and the mirrors. They
are still kept in the archive;
1. `svn commit` your changes.

After committing your changes, the [Apache Felix Dist](https://www.apache.org/dist/felix)
folder is immediately updated. Updating the mirrors takes another few hours
(up to a day).

### Release to the Maven Repository

1. Login to [Apache Nexus Repository](https://repository.apache.org) with your Apache SVN credentials;
1. Click on *Staging*;
1. Find your closed staging repository, select it, and click the *Release* button;
1. Click on *Repositories*;
1. Select the *Releases* repository;
1. Validate that your artifacts are all there.

### Release Bundles to the OBR

If you're releasing bundles, you can also add them to the Felix Release OBR. To do this, execute the following command
in a checkout of the release tag (target/checkout if is still around, otherwise a new one):

    :::bash
    $ export site=# your checkout of (https://svn.apache.org/repos/asf/felix/site/trunk/content)
    $ export obr=${site}/obr
    $ mvn clean install \
        org.apache.felix:maven-bundle-plugin:deploy \
        -DprefixUrl=https://repo1.maven.org/maven2 \
        -DremoteOBR=releases.xml \
        -DaltDeploymentRepository=apache.website::default::file:///${obr}
    $ svn commit -m"..." ${obr}/repository.xml
 
After committing the site must be published. If you release to OBR before [updating the site](update-the-site) you can defer publishing until after that.
Otherwise publish the site by visiting the [Site Publication](https://cms.apache.org/felix/publish) link.

The [releases](https://felix.apache.org/obr/releases.xml) page is updated immediately.

**Note**: the project building the bundle must use the [{{ maven-bundle-plugin.headers.title }}]({{ maven-bundle-plugin.path }}) and use a version equal to or higher than 1.4.2.

**Note**: with Maven 3, you must add an extension to your `<build>` providing the SCP/SSH protocol:

    :::xml
    <build>
    ...
      <extensions>
        <extension>
          <groupId>org.apache.maven.wagon</groupId>
          <artifactId>wagon-ssh</artifactId>
          <version>1.0-beta-6</version>
        </extension>
      </extensions>  
    </build>


### Update the Site

1. Update the news section on the website at [news](https://cms.apache.org/redirect?uri=http%3A//felix.apache.org/news.html);
1. Update the download page on the website at [downloads](https://cms.apache.org/redirect?uri=http%3A//felix.apache.org/downloads.list) to point to the new release;
1. Commit your changes (click the commit link);
1. [Publish the site](https://cms.apache.org/felix/publish).

For the last two tasks, it's better to give the mirrors some time to distribute the uploaded artifacts (one day should be fine). This ensures that once the website (news and download page) is updated, people can actually download the artifacts.


## Update JIRA

Go to [Admin](https://issues.apache.org/jira/secure/project/ViewProject.jspa?pid=12310100) section on the FELIX JIRA and mark the Y.Z version as released - create version Y.Z+1, if that hasn't already been done.


## Publish Generated Documentation

This procedure applies currently only to the `maven-bundle-plugin`:

1. Checkout the release tag of the plugin 
1. Run `mvn clean package site`
1. Create a new folder for the new version at `https://svn.apache.org/repos/asf/felix/site/trunk/content/components/bundle-plugin-archives/bundle-plugin-<version>` and publish the generated site from `target/site` there
1. Remove the previous documentation from `components/bundle-plugin` and SVN-copy the new version there as well


## Create an Announcement


    :::text
    To: "Felix Users List" <users@felix.apache.org>
    Subject: [ANN] Felix XXX version Y.Z Released
    
    The Felix team is pleased to announce the release of Felix XXX version Y.Z
    
    <<insert short description of the sub-project>>
    
      https://felix.apache.org/site/apache-felix-XXX.html
    
    This release is available from https://felix.apache.org/site/downloads.cgi and Maven:
    
      <dependency>
        <groupId>org.apache.felix</groupId>
        <artifactId>org.apache.felix.XXX</artifactId>
        <version>Y.Z</version>
      </dependency>
    
    Release Notes:
    
    <<insert release notes in text format from JIRA>>
    
    Enjoy!
    
    -The Felix team


Remember to forward this announcement to `users@felix.apache.org` - try *not* to cross-post (CC:\) announcements to both user and dev lists.

*Remind Carsten about this release when he writes the next board report ;)*

## Appendix A: create and add your key to https://www.apache.org/dist/felix/KEYS

If you are using a *nix system with a working OpenSSH, GnuPG, and bash you can create and add your own key with the following command:

    :::bash
    $ gpg --gen-key

When gpg asks for e-mail linked the key you *MUST USE* the <committer>@apache.org one.
When gpg asks for comment linked the key you *SHOULD USE* "CODE SIGNING KEY".
  
Second, *Add the key to* (https://dist.apache.org/repos/dist/release/felix/KEYS).

Only PMC members can commit to files in the dist area, so you should do the key export in the 
shell commands below, and send the results along to a friendly PMC member for assistance.

Type the following command replacing the word e-mail with your Apache's one (<committer>@apache.org). To update you have to checkout the Felix
dist release repository (you also need this to publish a release): 

    :::bash
    $ (gpg --list-sigs e-mail && gpg --export --armor e-mail) > toadd.key

Provide the file to a PMC member, who will:

    :::bash
    $ svn checkout https://dist.apache.org/repos/dist/release/felix felix-dist
    $ cat toadd.key >> felix-dist/KEYS
    $ scn commit -m"KEYS += <committer>" felix-dist/KEYS

You are now *DONE* and the changes are visible on https://www.apache.org/dist/felix/KEYS.