uPortal-Project/uportal-home

# Releasing uPortal-home

## Apache release rules

This project has [adopted Apache rules][] with necessary or pragmatic local adaptations.

Release authorization, or the delegation of release authority to one or more release engineers, should be documented by [a suitable vote][Apache Release Policy re Release Approval] of [the uPortal-home Committers][] on [uportal-dev@][].

## Release steps

### Finalize documentation

Before cutting the release, review the [CHANGELOG][], and verify what kind of release is appropriate: major, minor, or patch (x.y.z respectively). (See [Semantic Versioning][].)

### Java release

Use the Maven command line client to prepare, build, sign, and publish to the
Sonatype-hosted central open source software artifact repository.

```sh
mvn release:prepare
mvn release:perform
```

`release:prepare` will ask you some questions.
uPortal-home depends upon a SNAPSHOT version of uPortal-app-framework
in development, so that the latest uPortal-home SNAPSHOT uses the latest
uPortal-app-framework SNAPSHOT. When releasing, it's traditional to resolve
SNAPSHOT dependencies to concrete versions so that the release's dependencies
are well defined. So if uPortal-home is depending upon uPortal-app-framework
19.0.2-SNAPSHOT before your release, you might have it depend on the actual
19.0.2 release for the release, and then depend upon 19.0.3-SNAPSHOT
(the new latest snapshot) of uPortal-app-framework for development after the
release.

_Iff it went well_, push the 2 new git commits to
uPortal-Project/uportal-home:master . Both of these commits were
generated by the mvn release commands. The first is the commit that set the
version numbers to the version you released; the second is the commit that set
the version numbers to the new snapshot.

Assuming that your `origin` is uPortal-project/uPortal-home, you can
push those commits using:

```sh
git push origin master
git push origin uportal-home-maven-<version> *
```
* Note: This command may result with errors. You may skip this step if a new tag has been created. Run `git tag -l` to verify.

If you call canonical something else (like, say, `upstream`), you'll need to
adjust the git push commands accordingly.

Then,

[Release Maven artifacts][] from [central staging repository][central Maven staging repository]

### Updating JIRA issues

UW-Madison uses a private JIRA instance tracking work on this project.
In practice committers serving as release engineers on uportal-home are
UW-Madison staff with access to this private JIRA.

In the [`MUMUP` JIRA project][], find the last unreleased patch version. If the
current release is a major or minor update, rename the version accordingly.
Apply that version as a `Fix Version` to the JIRA tickets resolved since the
last release. When all tickets have been added, `Release` the version and
create the next patch version.

[Semantic Versioning]: http://semver.org/
[CHANGELOG]: https://github.com/uPortal-Project/uportal-home/blob/master/CHANGELOG.md
[adopted Apache rules]: https://github.com/uPortal-Project/uportal-home/blob/master/committers.md#rules
[Apache Release Policy re Release Approval]: http://www.apache.org/legal/release-policy.html#release-approval
[the uPortal-home Committers]: https://github.com/uPortal-Project/uportal-home/blob/master/committers.md#who-are-the-committers
[uportal-dev@]: https://groups.google.com/a/apereo.org/forum/#!forum/uportal-dev
[Release Maven artifacts]: https://central.sonatype.org/pages/releasing-the-deployment.html
[central Maven staging repository]: https://oss.sonatype.org/#stagingRepositories
[`MUMUP` JIRA project]: https://jira.doit.wisc.edu/jira/projects/MUMUP?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased