...
| Code Block |
|---|
mvn clean install -DskipTests=true mvn clean apache-rat:check |
Generate CHANGES.txt
Currently we don't keep CHANGES.txt in repo and only generate it on demand. To find previous example, search in previous release branch.
To generate CHANGES.txt, please pull information from JIRA and git log. To get all JIRAs of this release, use filter 'fixVersion = <version> AND resolution = resolved'. To get all commits of this release, you can find the last commit in last release in corresponding release branch and do a git diff against current release branch.
There are cases where information from JIRAs is inconsistent with that from git log (which shouldn't happen but unfortunately happens sometime...). For example, committer may forget to mark JIRA as resolved or set the fix version, or commit message contains wrong JIRA number. So it's better to check both side.
Several things need notice:
- Incompatible changes should be found by using filter "Hadoop Flags" = "Incompatible change". Don't search by labels 'incompatible' or something similar.
- Umbrella JIRA should be listed in individually (instead of getting mixed in non-umbrella jira)
- Changes are grouped by release version. If one patch gets committed into multiple branches, put this change in the oldest one. For example, if a patch is committed in branch 0.9.0 (current release), 0.8.6 (unreleased of 0.8 line), this change should be listed in the section of 0.8.6.
Update Version Number if Required
| Code Block |
|---|
mvn versions:set -DnewVersion="x.y.z"
Modify CHANGES.txt to set the release date to when the vote will likely end ( +3 or 4 days from the vote start ).
If needed, add missing entries in CHANGES.txt for this release's ChangeLog using the output from "git log --pretty=oneline"
Commit and push all the changes.
|
Create a Release Tag
| Code Block |
|---|
git tag -a release-x.y.z-rc0 -m 'Tez x.y.z RC0' git push --tags origin |
...
Copy the Release Candidate bits from https://dist.apache.org/repos/dist/dev/tez/ to https://dist.apache.org/repos/dist/release/tez/. Create a new directory with the release number and copy the artifacts into that directory (use an svn mv to retain history). If needed, update STABLE to point to the new release. This step need to be done by PMC, or PMC has to grant the permission of dist/release to release manager.
As an example
| Code Block |
|---|
svn mv https://dist.apache.org/repos/dist/dev/tez/x.y.z-rc0 https://dist.apache.org/repos/dist/release/tez/x.y.z |
...
Note that it takes 24 hours for the changes to propagate to the mirrors.
Wait 24 hours and verify that the bits are available in the mirrors before sending an announcement. Sometime it takes longer than 24 hours.
Update DOAP file for Tez
Update Tez_DOAP.rdf at the top of the source tree in the master branch to update the releases section for this new release.
...
Regards,
The Tez Team
JIRA Updates
The followings have to be done by PMC since only PMC has the required permission.
Find all JIRAs that were fixed in this release ( i.e. Fix Version set to the released version ) and do a bulk edit to mark them all as Closed. A useful point to note is that when doing this bulk update, mail notifications should be turned off to avoid triggering a barrage of emails being sent out. Find all JIRAs with fix version x.y.z and not-resolved/not-closed and remove the fix version. Once this is complete, using the JIRA Administration tab, mark the x.y.z as released and set the appropriate release date. Create the next version if its already not done. Find all JIRAs with target version x.y.z and not-resolved/not-closed and change the target version to the next release following the above bulk update process.
...