Versions Compared

Old Version 39

changes.mady.by.user Larry McCay

Saved on

compared with

New Version 40

changes.mady.by.user Larry McCay

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

unmigrated-inline-wiki-markup
{hide-from:user=*}
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.
{hide-from}

...

 Table of Contents
Prerequisites
Before entering into this process you need to ensure you will be able to cryptographically sign the final result in such a way that others can validate the signature. This can be a confusing process. Here are links to several documents that should help.
...
...
Discuss
Send a [DISCUSS] email to the dev@knox list proposing a release.
Prepare
In preparation for each release there are a number of sub-steps required to ensure that that the project's repository is in a suitable state for branching.
Start with clean local repo
This can be a fresh clone or just a repo that has no pending changes or extraneous files in.
Switch to the branch that you will branch from
In this step we need to check out the previous release branch or some other existing branch from which we will create our new one.
List existing branches:
 Code Block
]

h1. Discuss

Send a \[DISCUSS\] email to the dev@knox list proposing a release.

h1. Prepare

In preparation for each release there are a number of sub-steps required to ensure that that the project's repository is in a suitable state for branching.

h2. Start with clean local repo
This can be a fresh clone or just a repo that has no pending changes or extraneous files in.

h2. Switch to the branch that you will branch from
In this step we need to check out the previous release branch or some other existing branch from which we will create our new one.

List existing branches:
{code}
git branch -al

* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/v0.2.0
  remotes/origin/v0.3.0
  remotes/origin/v{X.Y.Z-1}
{code}


Check out the previous 
Check out the previous (release) 
...
 branch:

{
 Code Block
}
git checkout -t origin/v{X.Y.Z-1}
{code}

h1. 
Tag Branch Point and Branch
This step tags the point in time of when the branching starts within the remote repo.
 Code Block
Tag Branch Point and Branch
This step tags the point in time of when the branching starts within the remote repo.

{code}
git tag --annotate v{X.Y.Z}-branch --message "Branch point for v{X.Y.Z}"
git push origin --tags
{code}

h1. Switch to the new branch
Check out the branch that is intended for this release:
{code}
Switch to the new branch
Check out the branch that is intended for this release:
 Code Block
git checkout -b v{X.Y.Z}
git push --set-upstream origin v{X.Y.Z}

Clone & Checkout Branch
This step does a couple things for us:
  • it ensures that the branch is actually there and available
  • it ensures that our local repository to work from is clean
 Code Block
{code}

h1. Clone & Checkout Branch
This step does a couple things for us:
* it ensures that the branch is actually there and available
* it ensures that our local repository to work from is clean

{code}
git clone https://git-wip-us.apache.org/repos/asf/incubator-knox.git knox-{X.Y.Z}
cd knox-{X.Y.Z}
git checkout -t origin/v{X.Y.Z}
git pull
{code}

h2. Cherry pick previous commits from master
You can use 
Cherry pick previous commits from master
You can use cherry-pick 
...
 to 
...
 pull 
...
 commits 
...
 in 
...
 from 
...
 existing 
...
 branches.
...
To 
...
 pull 
...
 the 
...
 changeset 
...
 for 
...
 the 
...
 commit 
...
 at 
...
 the 
...
 tip 
...
 of 
...
 the 
...
 master 
...
 branch:

{
 Code Block
}
git cherry-pick origin/master
{code}

h2. Search for and replace all occurrences of the previous branch versions within the project's files
All build artifacts that contain the previous branch's version need to be updated with the new version to reflect this new branch.

{
Search for and replace all occurrences of the previous branch versions within the project's files
All build artifacts that contain the previous branch's version need to be updated with the new version to reflect this new branch.
 Code Block
code}
grep -r "0\.3\.0" .
{code}


Change 
...
 all 
...
 occurrences 
...
 as 
...
 appropriate.
...
Update 
...
 version 
...
 numbers 
...
 on 
...
 master 
...
 branch 
...
 (from 
...
 A.B.C-SNAPSHOT 
...
 to 
...
 D.E.F-SNAPSHOT) 
...
 and 
...
 push 
...
 changes
...
Update 
...
 version 
...
 numbers 
...
 on 
...
 release 
...
 branch 
...
 (from 
...
 A.B.C-SNAPSHOT 
...
 to 
...
 A.B.C) 
...
 and 
...
 push 
...
 changes
...
Update 
...
 CHANGES
...
Update 
...
 CHANGES 
...
 with 
...
 release 
...
 date 
...
 (Release 
...
 X.Y 
...
 - 
...
 MM/dd/yyyy) 
...
 and 
...
 (if 
...
 needed) 
...
 add 
...
 additional 
...
 changelog 
...
 entries.
...

 The 
...
 CHANGES 
...
 file 
...
 can 
...
 be 
...
 found 
...
 in 
...
 gateway-release/home
...
Update 
...
 documentation
...
Build, 
...
 Test 
...
 and 
...
 Push 
...
 Changes

{
 Code Block
}
git pull
git commit --all --message "Updating branch."
ant verify
git push
{code}

h2. Create a new Jenkins job to build the release.  It should call these two commands.  It is probably best to copy the previous releases job.
Assuming that you have proper karma for creating new Jenkins jobs, you will see a link to create a new one.
From that link you will be provided a page to select how to proceed; select copy existing job.

Ensure that the following form reflects the following values within various form elements:
* maven
* -Prelease clean install
* ant post-build

Be sure to change any versions to reflect "v\
Create a new Jenkins job to build the release. It should call these two commands. It is probably best to copy the previous releases job.
Assuming that you have proper karma for creating new Jenkins jobs, you will see a link to create a new one.
 From that link you will be provided a page to select how to proceed; select copy existing job.
Ensure that the following form reflects the following values within various form elements:
  • maven
  • -Prelease clean install
  • ant post-build
Be sure to change any versions to reflect "v{X.Y.Z
...
}"
...
Upon 
...
 successful 
...
 creation 
...
 of 
...
 the 
...
 new 
...
 job, 
...
 you 
...
 may 
...
 manually 
...
 kick 
...
 off 
...
 a 
...
 build 
...
 with 
...
 the 
...
 Build 
...
 Now 
...
 button.
...
Download 
...
 the 
...
 release 
...
 candidate

{
 Code Block
}
ant download-candidate
{code}

h2. Sanity Test

Do some basic manual testing to see if release looks
Sanity Test
Do some basic manual testing to see if release looks ok. For example do and install and run through a few of the samples.
Sign
 Code Block
 ok.  For example do and install and run through a few of the samples.

h1. Sign
{code}
ant sign-candidate
{code}

This 
...
 will 
...
 prompt 
...
 you 
...
 for 
...
 your 
...
 passphrase 
...
 for 
...
 each 
...
 signed 
...
 archive.
...
Verify 
...
 Signatures
...
Verify 
...
 the 
...
 hashes 
...
 and 
...
 signatures. 
...
 First 
...
 change 
...
 into 
...
 the 
...
 distribution 
...
 directory.

{
 Code Block
}
cd candidate
{code}


Verify 
...
 the 
...
 signatures 
...
 for 
...
 both 
...
 the 
...
 source 
...
 and 
...
 binary 
...
 distribution. 
...
Note: 
...
 This 
...
 assumes 
...
 that 
...
 gpg 
...
 is 
...
 installed.
_
{
 Code Block
}
gpg --verify knox-{X.Y.Z}-src.zip.asc knox-{X.Y.Z}-src.zip
gpg --verify knox-{X.Y.Z}.zip.asc knox-{X.Y.Z}.zip
{code}


Verify 
...
 the 
...
 SHA-1 
...
 hashes 
...
 for 
...
 both 
...
 the 
...
 source 
...
 and 
...
 binary 
...
 distribution. 
...
Note: 
...
 This 
...
 assumes 
...
 a 
...
 Linux 
...
 or 
...
 MacOS 
...
 environment 
...
 with 
...
 openssl 
...
 installed.
_
{
 Code Block
}
cat knox-{X.Y.Z}-src.zip.sha && openssl sha1 knox-{X.Y.Z}-src.zip 
cat knox-{X.Y.Z}.zip.sha && openssl sha1 knox-{X.Y.Z}.zip 
{code}


Verify 
...
 the 
...
 MD5 
...
 digest 
...
 for 
...
 both 
...
 the 
...
 source 
...
 and 
...
 binary 
...
 distribution. 
...
Note: 
...
 This 
...
 assumes 
...
 a 
...
 Linux 
...
 or 
...
 MacOS 
...
 environment 
...
 with 
...
 openssl 
...
 installed.
_
{
 Code Block
}
cat knox-{X.Y.Z}-src.zip.md5 && openssl md5 knox-{X.Y.Z}-src.zip
cat knox-{X.Y.Z}.zip.md5 && openssl md5 knox-{X.Y.Z}.zip

Tag Release Candidate
 Code Block
{code}

h1. Tag Release Candidate
{code}
git tag --annotate vX.Y.Z-rcN --message "vX.Y.Z release candidate N"
git push origin --tags
{code}

h1.
Stage
Follow the instructions output by the sign step above. Basically execute this command.
 Code Block
 Stage

Follow the instructions output by the sign step above.  Basically execute this command.

{code}
cd ..
ant stage-candidate
{code}

h1. Community reviews the RC


Community reviews the RC
https://dist.apache.org/repos/dist/dev/incubator/knox/
...
Vote
Send a [VOTE
...
] 
...
 email 
...
 to 
...
 the 
...
 dev@knox 
...
 list. 
...
 A 
...
 template 
...
 was 
...
 output 
...
 by 
...
 the 
...
 sign 
...
 step 
...
 above 
...
 as 
...
target/vote.eml
...
.


{
 Code Block
}
From: {release-manager}
To: dev@knox.incubator.apache.org
Subject: [VOTE] Release Apache Knox (Incubator) {X.Y.Z}

A candidate for the Apache Knox (Incubator) {X.Y.Z} release is available at:

http://people.apache.org/~{release-manager}/knox/{X.Y.Z}/

The release candidate is a zip archive of the sources in:

https://git-wip-us.apache.org/repos/asf/incubator-knox.git
Branch {X.Y.Z}

The SHA1 checksum of the archive is {checksum}.

Please vote on releasing this package as Apache Knox (Incubator) {X.Y.Z}.
The vote is open for the next 72 hours and passes if a majority of at
least three +1 Apache Knox (Incubator) PMC votes are cast.

[ ] +1 Release this package as Apache Knox (Incubator) {X.Y.Z}
[ ] -1 Do not release this package because...
{code}

h2. Iterate based on feedback until vote passes

h2. Once vote passes, tag the release:
{code}
Iterate based on feedback until vote passes
Once vote passes, tag the release:
 Code Block
git tag --annotate v{X.Y.Z}-release --message "Release of v{X.Y.Z}"
git push origin --tags

Promote
 Code Block
{code}

h2. Promote

{code}
ant promote-release
{code}

h2. Verify that the results are accessible.

Verify that the results are accessible.
https://dist.apache.org/repos/dist/release/incubator/knox/
...
Wait 
...
 24 
...
 hours 
...
 for 
...
 release 
...
 to 
...
 propagate 
...
 to 
...
 mirrors.
...
Update 
...
 site
...
Update 
...
 news 
...
 in 
...
 src/site/src/documentation/content/xdocs/index.xml 
...
 and 
...
 for 
...
 main 
...
 lucene.apache.org 
...
 site 
...
 stored 
...
 at 
...
https://svn.apache.org/repos/asf/lucene/site/
...
. 
...
 The 
...
 second 
...
 change 
...
 may 
...
 require 
...
 additional 
...
 rights
...
Create 
...
 version 
...
 in 
...
 JIRA 
...
 for 
...
 release 
...
 X.Y.
...
Send 
...
 announcements 
...
 to 
...
 the 
...
 user 
...
 and 
...
 developer 
...
 lists.
...
Update 
...
 CHANGES 
...
 with 
...
 header 
...
 for 
...
 new 
...
 changes
...
 Include Page
Footer
Footer