You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@amaterasu.apache.org by Yaniv Rodenski <ya...@shinto.io> on 2018/02/17 01:31:50 UTC
[DISCUSS] release procedure
Hi All,
Based on Davor's and JB's feedback I would like to start the discussion on
our release procedure.
I suggest starting with a minimal process and add controls if and when
needed, based on that I suggest the following minimal procedure, based on
@Davor's Beam example below.
Please note the following major differences:
1. The prepare to release section was minimized to managing versions in
JIRA, we aim to automate the entire release process to have the release
manager creating a *version branch* which will launch an automated *release
build *that will sign the version etc.
2. As far as I can figure out, after voting on the incubator dev@ list
we need to initiate a vote on the incubator general@ list, I have left
an empty section for that, *can any of the mentors help fill that out*?
3. Additional question for our mentors, I have stated that the release
requires the approval of 3 IPMC members, is that correct?
4. In JIRA, I have minimized the process and currently, no workflow
to Triage release-blocking issues is proposed. I propose to differ this
discussion to the first occasion when we will encounter such an issue.
5. I also propose to differ the discussion on the process for release
of documentation and releases to online repos such as Maven/PyPi etc to the
first occasion when we do release those.
== Introduction ==
The Apache Amaterasu (Incubating) project periodically declares and
publishes releases. A release is one or more packages of the project
artifact(s) that are approved for general public distribution and use. They
may come with various degrees of caveat regarding their perceived quality
and potential for change, such as “alpha”, “beta”, “incubating”, “stable”,
etc.
The Amaterasu community treats releases with great importance. They are a
public face of the project and most users interact with the project only
through the releases. Releases are signed off by the entire Amaterasu
community in a public vote.
Each release is executed by a *Release Manager*, who is selected among
the Amaterasu
Committers <http://incubator.apache.org/projects/amaterasu.html>. This
document describes the process that the Release Manager follows to perform
a release. Any changes to this process should be discussed and adopted on
the dev@ mailing list.
Please remember that publishing software has legal consequences. This guide
complements the foundation-wide Product Release Policy
<http://www.apache.org/dev/release.html> and Release Distribution Policy
<http://www.apache.org/dev/release-distribution>.
== Overview ==
1. Decide to release
2. Managing the new version in JIRA
3. Build a release candidate
4. Vote on the release candidate
5. If necessary, fix any issues and go back to step 3.
6. Finalize the release
7. Promote the release
=== Decide to release ===
Deciding to release and selecting a *Release Manager* is the first step of
the release process. This is a consensus-based decision of the entire
community.
Anybody can propose a release on the dev@ mailing list, giving a solid
argument and nominating a committer as the Release Manager (including
themselves). There’s no formal process, no vote requirements, and no timing
requirements. Any objections should be resolved by consensus before
starting the release.
Checklist to proceed to the next step:
1. Community agrees to release
2. Community selects a Release Manager
=== Managing the new version in JIRA ===
When contributors resolve an issue in JIRA, they are tagging it with a
release that will contain their changes.
With a planned release currently underway, new issues should be resolved
against a subsequent future release. Therefore, Release manager should
create a release item for this subsequent release, as follows:
1. In JIRA, navigate to
*Amaterasu -> Administration -> versions *
2. Add a new release: choose the next minor version number compared to
the one currently underway, select today’s date as the *Start Date* and
click *Add*.
With unplanned releases such as hot-fixes, a new version should be created
representing that release. Issues that will be included in that release,
should be updated to reflect that.
=== Review Release Notes in JIRA ===
JIRA automatically generates Release Notes based on the *Fix Version* field
applied to issues. Release Notes are intended for Amaterasu Users (not
Amaterasu committers/contributors). You should ensure that Release Notes
are informative and useful.
Open the release notes from the version status page
<https://issues.apache.org/jira/projects/AMATERASU?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased>
by choosing the release underway and clicking Release Notes.
You should verify that the issues listed automatically by JIRA are
appropriate to appear in the Release Notes. Specifically, issues should:
- Be appropriately classified as *Bug*, *New Feature*, *Improvement*,
etc.
- Represent noteworthy user-facing changes, such as new functionality,
backward-incompatible API changes, or performance improvements.
- Have occurred since the previous release; an issue that was introduced
and fixed between releases should not appear in the Release Notes.
- Have an issue title that makes sense when read on its own.
Adjust any of the above properties to improve clarity and presentation of
the Release Notes.
=== Create an RC branch ===
Creating an RC release branch will initiate the release build process
which, if successful will create the released version.
Check out the version of the codebase from which you start the release. For
a new minor or major release, this may be *HEAD* of the *master* branch. To
build a hotfix/incremental release, instead of the *master* branch, use the
release tag of the release being patched. (Please make sure your cloned
repository is up-to-date before starting.)
$ *git checkout **<master branch OR release tag>*
Next, create a release branch with the version_ prefix followed by the
version number and followed by the _rc suffix:
$ *git checkout -b version_[version number]_rc*
For example, the release branch for version 0.2.0-incubating should be
created as follows"
$ *git checkout -b version_0.2.0-incubating*
Next, you will need to push the new branch to the remote as follows:
$ *git push origin version_**[version number]*
=== Vote on the release candidate ===
Once you have built and individually reviewed the release candidate, please
share it for the community-wide review. Please review foundation-wide voting
guidelines <http://www.apache.org/foundation/voting.html> for more
information.
Start the review-and-vote thread on the dev@ mailing list. Here’s an email
template; please adjust as you see fit.
--------------------------------------------------------------------------------------
From: Release Manager
To: dev@amaterasu.incubator.apache.org
Subject: [VOTE] Release 1.2.3, release candidate #3
Hi everyone,
Please review and vote on the release candidate #3 for the version 1.2.3,
as follows:
[ ] +1, Approve the release
[ ] -1, Do not approve the release (please provide specific comments)
The complete staging area is available for your review, which includes:
* JIRA release notes [1],
* the official Apache source release to be deployed to dist.apache.org [2],
which is signed with the key with fingerprint FFFFFFFF [3],
* all artifacts to be deployed to the Maven Central Repository [4],
* source code tag "v1.2.3-RC3" [5],
* website pull request listing the release and publishing the API reference
manual [6].
* Java artifacts were built with Maven MAVEN_VERSION and OpenJDK/Oracle JDK
JDK_VERSION.
* Python artifacts are deployed along with the source release to the
dist.apache.org [2].
The vote will be open for at least 72 hours. It is adopted by majority
approval, with at least 3 PMC affirmative votes.
Thanks,
Release Manager
[1] link
[2] link
[3] https://dist.apache.org/repos/dist/release/incubator-amaterasu/KEYS
[4] link
[5] link
[6] link
--------------------------------------------------------------------------------------
=== Mentors help needed
Mentors, please elaborate on how the voting process should work for an
incubating project.
======================================
If there are any issues found in the release candidate, reply on the vote
thread to cancel the vote. There’s no need to wait 72 hours. Proceed
to the *Fix
Issues* step below and address the problem. However, some issues don’t
require cancellation. For example, if an issue is found in the website pull
request, just correct it on the spot and the vote can continue as-is.
If there are no issues, replay on the vote thread to close the voting.
Then, tally the votes in a separate email. Here’s an email template; please
adjust as you see fit.
--------------------------------------------------------------------------------------
From: Release Manager
To: dev@amaterasu.incubator.apache.org
Subject: [RESULT] [VOTE] Release 1.2.3, release candidate #3
I'm happy to announce that we have unanimously approved this release.
There are XXX approving votes, XXX of which are binding:
* approver 1
* approver 2
* approver 3
* approver 4
There are no disapproving votes.
Thanks everyone
--------------------------------------------------------------------------------------
Checklist to proceed to the finalization step:
1. Community votes to release the proposed candidate, with at least
three approving IPMC votes
=== Fix any issues ===
Any issues identified during the community review and vote should be fixed
in this step.
Code changes should be proposed as standard pull requests to the
*master* branch
and reviewed using the normal contributing process.
For standard releases, this should be enough because during the release
process, committers should avoid merging non-related PRs to master. and a
new version branch should be created from the *master* branch.
However, if non-related PRs ware merged or the release is from a release
branch, relevant changes should be cherry-picked into the release branch.
The cherry-pick commits should then be proposed as the pull requests
against the release branch, again reviewed and merged using the normal
contributing process.
Once all issues have been resolved, you should go back and build a new
release candidate containing these changes.
Checklist to proceed to the finalization step:
1. Issues identified during vote have been resolved, with fixes
committed to the release branch.
=== Finalize the release ===
Once the release candidate has been reviewed and approved by the community,
the release should be finalized. This involves creating a release branch
which is the same procedure as building an RC branch with the sole
difference of not having the _rc suffix.
=== Promote the release ===
Once the release has been finalized, the last step of the process is to
promote the release within the project and beyond.
==== Apache Mailing Lists ===
Announce on the dev@ mailing list that the release has been finished.
Announce on the release on the general@incubator.apache.org mailing list,
listing major improvements and contributions.
Announce the release on the announce@apache.org mailing list.
==== Amaterasu Blog ====
Major or otherwise important releases should have a blog post. Write one if
needed for this particular release. Minor releases that don’t introduce new
major functionality don’t necessarily need to be blogged.
==== Social Media ====
Tweet, post on Facebook, LinkedIn, and other platforms. Ask other
contributors to do the same.
Checklist to proceed to the finalization step:
1. Release announced on the dev@ mailing list.
2. A blog post published, if applicable.
3. Release recorded in reporter.apache.org.
4. Release announced on social media.
5. Completion declared on the general@incubator.apache.org mailing list.
--
Yaniv Rodenski
Re: [DISCUSS] release procedure
Posted by Yaniv Rodenski <ya...@shinto.io>.
Excellent, I'll add this to the Policy and probably push it to the website
over the weekend
On Mon, Feb 19, 2018 at 9:49 AM, Davor Bonaci <da...@apache.org> wrote:
> >
> > 2. As far as I can figure out, after voting on the incubator dev@
> list
> > we need to initiate a vote on the incubator general@ list, I have
> left
> > an empty section for that, *can any of the mentors help fill that
> out*?
> >
>
> Vote first here on dev@amaterasu, then general@incubator.
>
>
> > 3. Additional question for our mentors, I have stated that the release
> > requires the approval of 3 IPMC members, is that correct?
> >
>
> 3 PPMC should approve before presenting to Incubator. 3 IPMC members then
> to release.
>
--
Yaniv Rodenski
Re: [DISCUSS] release procedure
Posted by Davor Bonaci <da...@apache.org>.
>
> 2. As far as I can figure out, after voting on the incubator dev@ list
> we need to initiate a vote on the incubator general@ list, I have left
> an empty section for that, *can any of the mentors help fill that out*?
>
Vote first here on dev@amaterasu, then general@incubator.
> 3. Additional question for our mentors, I have stated that the release
> requires the approval of 3 IPMC members, is that correct?
>
3 PPMC should approve before presenting to Incubator. 3 IPMC members then
to release.
Re: [DISCUSS] release procedure
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
The vote is always first in the podling (dev mailing list).
To pass, the vote should have three mentor +1 votes. Then, the vote is forwarded
to incubator (general mailing list) where it needs 3 IPMC +1 votes.
Regards
JB
On 02/17/2018 02:31 AM, Yaniv Rodenski wrote:
> Hi All,
>
> Based on Davor's and JB's feedback I would like to start the discussion on
> our release procedure.
>
> I suggest starting with a minimal process and add controls if and when
> needed, based on that I suggest the following minimal procedure, based on
> @Davor's Beam example below.
>
> Please note the following major differences:
>
> 1. The prepare to release section was minimized to managing versions in
> JIRA, we aim to automate the entire release process to have the release
> manager creating a *version branch* which will launch an automated *release
> build *that will sign the version etc.
> 2. As far as I can figure out, after voting on the incubator dev@ list
> we need to initiate a vote on the incubator general@ list, I have left
> an empty section for that, *can any of the mentors help fill that out*?
> 3. Additional question for our mentors, I have stated that the release
> requires the approval of 3 IPMC members, is that correct?
> 4. In JIRA, I have minimized the process and currently, no workflow
> to Triage release-blocking issues is proposed. I propose to differ this
> discussion to the first occasion when we will encounter such an issue.
> 5. I also propose to differ the discussion on the process for release
> of documentation and releases to online repos such as Maven/PyPi etc to the
> first occasion when we do release those.
>
>
> == Introduction ==
>
> The Apache Amaterasu (Incubating) project periodically declares and
> publishes releases. A release is one or more packages of the project
> artifact(s) that are approved for general public distribution and use. They
> may come with various degrees of caveat regarding their perceived quality
> and potential for change, such as “alpha”, “beta”, “incubating”, “stable”,
> etc.
>
> The Amaterasu community treats releases with great importance. They are a
> public face of the project and most users interact with the project only
> through the releases. Releases are signed off by the entire Amaterasu
> community in a public vote.
>
> Each release is executed by a *Release Manager*, who is selected among
> the Amaterasu
> Committers <http://incubator.apache.org/projects/amaterasu.html>. This
> document describes the process that the Release Manager follows to perform
> a release. Any changes to this process should be discussed and adopted on
> the dev@ mailing list.
>
> Please remember that publishing software has legal consequences. This guide
> complements the foundation-wide Product Release Policy
> <http://www.apache.org/dev/release.html> and Release Distribution Policy
> <http://www.apache.org/dev/release-distribution>.
>
> == Overview ==
>
>
> 1. Decide to release
> 2. Managing the new version in JIRA
> 3. Build a release candidate
> 4. Vote on the release candidate
> 5. If necessary, fix any issues and go back to step 3.
> 6. Finalize the release
> 7. Promote the release
>
> === Decide to release ===
>
> Deciding to release and selecting a *Release Manager* is the first step of
> the release process. This is a consensus-based decision of the entire
> community.
>
> Anybody can propose a release on the dev@ mailing list, giving a solid
> argument and nominating a committer as the Release Manager (including
> themselves). There’s no formal process, no vote requirements, and no timing
> requirements. Any objections should be resolved by consensus before
> starting the release.
>
> Checklist to proceed to the next step:
>
>
> 1. Community agrees to release
> 2. Community selects a Release Manager
>
>
> === Managing the new version in JIRA ===
>
> When contributors resolve an issue in JIRA, they are tagging it with a
> release that will contain their changes.
>
> With a planned release currently underway, new issues should be resolved
> against a subsequent future release. Therefore, Release manager should
> create a release item for this subsequent release, as follows:
>
>
>
> 1. In JIRA, navigate to
> *Amaterasu -> Administration -> versions *
> 2. Add a new release: choose the next minor version number compared to
> the one currently underway, select today’s date as the *Start Date* and
> click *Add*.
>
>
> With unplanned releases such as hot-fixes, a new version should be created
> representing that release. Issues that will be included in that release,
> should be updated to reflect that.
>
> === Review Release Notes in JIRA ===
>
> JIRA automatically generates Release Notes based on the *Fix Version* field
> applied to issues. Release Notes are intended for Amaterasu Users (not
> Amaterasu committers/contributors). You should ensure that Release Notes
> are informative and useful.
>
> Open the release notes from the version status page
> <https://issues.apache.org/jira/projects/AMATERASU?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased>
> by choosing the release underway and clicking Release Notes.
>
> You should verify that the issues listed automatically by JIRA are
> appropriate to appear in the Release Notes. Specifically, issues should:
>
> - Be appropriately classified as *Bug*, *New Feature*, *Improvement*,
> etc.
> - Represent noteworthy user-facing changes, such as new functionality,
> backward-incompatible API changes, or performance improvements.
> - Have occurred since the previous release; an issue that was introduced
> and fixed between releases should not appear in the Release Notes.
> - Have an issue title that makes sense when read on its own.
>
> Adjust any of the above properties to improve clarity and presentation of
> the Release Notes.
>
> === Create an RC branch ===
>
> Creating an RC release branch will initiate the release build process
> which, if successful will create the released version.
>
> Check out the version of the codebase from which you start the release. For
> a new minor or major release, this may be *HEAD* of the *master* branch. To
> build a hotfix/incremental release, instead of the *master* branch, use the
> release tag of the release being patched. (Please make sure your cloned
> repository is up-to-date before starting.)
>
> $ *git checkout **<master branch OR release tag>*
>
> Next, create a release branch with the version_ prefix followed by the
> version number and followed by the _rc suffix:
>
> $ *git checkout -b version_[version number]_rc*
> For example, the release branch for version 0.2.0-incubating should be
> created as follows"
>
> $ *git checkout -b version_0.2.0-incubating*
>
> Next, you will need to push the new branch to the remote as follows:
> $ *git push origin version_**[version number]*
>
> === Vote on the release candidate ===
>
> Once you have built and individually reviewed the release candidate, please
> share it for the community-wide review. Please review foundation-wide voting
> guidelines <http://www.apache.org/foundation/voting.html> for more
> information.
>
> Start the review-and-vote thread on the dev@ mailing list. Here’s an email
> template; please adjust as you see fit.
> --------------------------------------------------------------------------------------
>
> From: Release Manager
>
> To: dev@amaterasu.incubator.apache.org
>
> Subject: [VOTE] Release 1.2.3, release candidate #3
>
>
> Hi everyone,
>
> Please review and vote on the release candidate #3 for the version 1.2.3,
> as follows:
>
> [ ] +1, Approve the release
>
> [ ] -1, Do not approve the release (please provide specific comments)
>
>
>
> The complete staging area is available for your review, which includes:
>
> * JIRA release notes [1],
>
> * the official Apache source release to be deployed to dist.apache.org [2],
> which is signed with the key with fingerprint FFFFFFFF [3],
>
> * all artifacts to be deployed to the Maven Central Repository [4],
>
> * source code tag "v1.2.3-RC3" [5],
>
> * website pull request listing the release and publishing the API reference
> manual [6].
>
> * Java artifacts were built with Maven MAVEN_VERSION and OpenJDK/Oracle JDK
> JDK_VERSION.
>
> * Python artifacts are deployed along with the source release to the
> dist.apache.org [2].
>
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
>
> Thanks,
>
> Release Manager
>
>
> [1] link
>
> [2] link
>
> [3] https://dist.apache.org/repos/dist/release/incubator-amaterasu/KEYS
>
> [4] link
>
> [5] link
>
> [6] link
> --------------------------------------------------------------------------------------
>
> === Mentors help needed
>
> Mentors, please elaborate on how the voting process should work for an
> incubating project.
>
> ======================================
>
>
> If there are any issues found in the release candidate, reply on the vote
> thread to cancel the vote. There’s no need to wait 72 hours. Proceed
> to the *Fix
> Issues* step below and address the problem. However, some issues don’t
> require cancellation. For example, if an issue is found in the website pull
> request, just correct it on the spot and the vote can continue as-is.
>
> If there are no issues, replay on the vote thread to close the voting.
> Then, tally the votes in a separate email. Here’s an email template; please
> adjust as you see fit.
> --------------------------------------------------------------------------------------
>
> From: Release Manager
>
> To: dev@amaterasu.incubator.apache.org
>
> Subject: [RESULT] [VOTE] Release 1.2.3, release candidate #3
>
>
> I'm happy to announce that we have unanimously approved this release.
>
>
> There are XXX approving votes, XXX of which are binding:
>
> * approver 1
>
> * approver 2
>
> * approver 3
>
> * approver 4
>
>
> There are no disapproving votes.
>
>
> Thanks everyone
>
> --------------------------------------------------------------------------------------
>
> Checklist to proceed to the finalization step:
>
> 1. Community votes to release the proposed candidate, with at least
> three approving IPMC votes
>
> === Fix any issues ===
>
> Any issues identified during the community review and vote should be fixed
> in this step.
>
> Code changes should be proposed as standard pull requests to the
> *master* branch
> and reviewed using the normal contributing process.
>
> For standard releases, this should be enough because during the release
> process, committers should avoid merging non-related PRs to master. and a
> new version branch should be created from the *master* branch.
>
> However, if non-related PRs ware merged or the release is from a release
> branch, relevant changes should be cherry-picked into the release branch.
> The cherry-pick commits should then be proposed as the pull requests
> against the release branch, again reviewed and merged using the normal
> contributing process.
>
> Once all issues have been resolved, you should go back and build a new
> release candidate containing these changes.
>
> Checklist to proceed to the finalization step:
>
>
> 1. Issues identified during vote have been resolved, with fixes
> committed to the release branch.
>
> === Finalize the release ===
>
> Once the release candidate has been reviewed and approved by the community,
> the release should be finalized. This involves creating a release branch
> which is the same procedure as building an RC branch with the sole
> difference of not having the _rc suffix.
>
> === Promote the release ===
>
>
> Once the release has been finalized, the last step of the process is to
> promote the release within the project and beyond.
>
> ==== Apache Mailing Lists ===
>
> Announce on the dev@ mailing list that the release has been finished.
>
> Announce on the release on the general@incubator.apache.org mailing list,
> listing major improvements and contributions.
>
> Announce the release on the announce@apache.org mailing list.
> ==== Amaterasu Blog ====
>
> Major or otherwise important releases should have a blog post. Write one if
> needed for this particular release. Minor releases that don’t introduce new
> major functionality don’t necessarily need to be blogged.
> ==== Social Media ====
>
> Tweet, post on Facebook, LinkedIn, and other platforms. Ask other
> contributors to do the same.
>
> Checklist to proceed to the finalization step:
>
> 1. Release announced on the dev@ mailing list.
> 2. A blog post published, if applicable.
> 3. Release recorded in reporter.apache.org.
> 4. Release announced on social media.
> 5. Completion declared on the general@incubator.apache.org mailing list.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: [DISCUSS] release procedure
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
+1
it sounds good to me.
It could be refine during the first release.
Regards
JB
On 02/17/2018 02:31 AM, Yaniv Rodenski wrote:
> Hi All,
>
> Based on Davor's and JB's feedback I would like to start the discussion on
> our release procedure.
>
> I suggest starting with a minimal process and add controls if and when
> needed, based on that I suggest the following minimal procedure, based on
> @Davor's Beam example below.
>
> Please note the following major differences:
>
> 1. The prepare to release section was minimized to managing versions in
> JIRA, we aim to automate the entire release process to have the release
> manager creating a *version branch* which will launch an automated *release
> build *that will sign the version etc.
> 2. As far as I can figure out, after voting on the incubator dev@ list
> we need to initiate a vote on the incubator general@ list, I have left
> an empty section for that, *can any of the mentors help fill that out*?
> 3. Additional question for our mentors, I have stated that the release
> requires the approval of 3 IPMC members, is that correct?
> 4. In JIRA, I have minimized the process and currently, no workflow
> to Triage release-blocking issues is proposed. I propose to differ this
> discussion to the first occasion when we will encounter such an issue.
> 5. I also propose to differ the discussion on the process for release
> of documentation and releases to online repos such as Maven/PyPi etc to the
> first occasion when we do release those.
>
>
> == Introduction ==
>
> The Apache Amaterasu (Incubating) project periodically declares and
> publishes releases. A release is one or more packages of the project
> artifact(s) that are approved for general public distribution and use. They
> may come with various degrees of caveat regarding their perceived quality
> and potential for change, such as “alpha”, “beta”, “incubating”, “stable”,
> etc.
>
> The Amaterasu community treats releases with great importance. They are a
> public face of the project and most users interact with the project only
> through the releases. Releases are signed off by the entire Amaterasu
> community in a public vote.
>
> Each release is executed by a *Release Manager*, who is selected among
> the Amaterasu
> Committers <http://incubator.apache.org/projects/amaterasu.html>. This
> document describes the process that the Release Manager follows to perform
> a release. Any changes to this process should be discussed and adopted on
> the dev@ mailing list.
>
> Please remember that publishing software has legal consequences. This guide
> complements the foundation-wide Product Release Policy
> <http://www.apache.org/dev/release.html> and Release Distribution Policy
> <http://www.apache.org/dev/release-distribution>.
>
> == Overview ==
>
>
> 1. Decide to release
> 2. Managing the new version in JIRA
> 3. Build a release candidate
> 4. Vote on the release candidate
> 5. If necessary, fix any issues and go back to step 3.
> 6. Finalize the release
> 7. Promote the release
>
> === Decide to release ===
>
> Deciding to release and selecting a *Release Manager* is the first step of
> the release process. This is a consensus-based decision of the entire
> community.
>
> Anybody can propose a release on the dev@ mailing list, giving a solid
> argument and nominating a committer as the Release Manager (including
> themselves). There’s no formal process, no vote requirements, and no timing
> requirements. Any objections should be resolved by consensus before
> starting the release.
>
> Checklist to proceed to the next step:
>
>
> 1. Community agrees to release
> 2. Community selects a Release Manager
>
>
> === Managing the new version in JIRA ===
>
> When contributors resolve an issue in JIRA, they are tagging it with a
> release that will contain their changes.
>
> With a planned release currently underway, new issues should be resolved
> against a subsequent future release. Therefore, Release manager should
> create a release item for this subsequent release, as follows:
>
>
>
> 1. In JIRA, navigate to
> *Amaterasu -> Administration -> versions *
> 2. Add a new release: choose the next minor version number compared to
> the one currently underway, select today’s date as the *Start Date* and
> click *Add*.
>
>
> With unplanned releases such as hot-fixes, a new version should be created
> representing that release. Issues that will be included in that release,
> should be updated to reflect that.
>
> === Review Release Notes in JIRA ===
>
> JIRA automatically generates Release Notes based on the *Fix Version* field
> applied to issues. Release Notes are intended for Amaterasu Users (not
> Amaterasu committers/contributors). You should ensure that Release Notes
> are informative and useful.
>
> Open the release notes from the version status page
> <https://issues.apache.org/jira/projects/AMATERASU?selectedItem=com.atlassian.jira.jira-projects-plugin%3Arelease-page&status=unreleased>
> by choosing the release underway and clicking Release Notes.
>
> You should verify that the issues listed automatically by JIRA are
> appropriate to appear in the Release Notes. Specifically, issues should:
>
> - Be appropriately classified as *Bug*, *New Feature*, *Improvement*,
> etc.
> - Represent noteworthy user-facing changes, such as new functionality,
> backward-incompatible API changes, or performance improvements.
> - Have occurred since the previous release; an issue that was introduced
> and fixed between releases should not appear in the Release Notes.
> - Have an issue title that makes sense when read on its own.
>
> Adjust any of the above properties to improve clarity and presentation of
> the Release Notes.
>
> === Create an RC branch ===
>
> Creating an RC release branch will initiate the release build process
> which, if successful will create the released version.
>
> Check out the version of the codebase from which you start the release. For
> a new minor or major release, this may be *HEAD* of the *master* branch. To
> build a hotfix/incremental release, instead of the *master* branch, use the
> release tag of the release being patched. (Please make sure your cloned
> repository is up-to-date before starting.)
>
> $ *git checkout **<master branch OR release tag>*
>
> Next, create a release branch with the version_ prefix followed by the
> version number and followed by the _rc suffix:
>
> $ *git checkout -b version_[version number]_rc*
> For example, the release branch for version 0.2.0-incubating should be
> created as follows"
>
> $ *git checkout -b version_0.2.0-incubating*
>
> Next, you will need to push the new branch to the remote as follows:
> $ *git push origin version_**[version number]*
>
> === Vote on the release candidate ===
>
> Once you have built and individually reviewed the release candidate, please
> share it for the community-wide review. Please review foundation-wide voting
> guidelines <http://www.apache.org/foundation/voting.html> for more
> information.
>
> Start the review-and-vote thread on the dev@ mailing list. Here’s an email
> template; please adjust as you see fit.
> --------------------------------------------------------------------------------------
>
> From: Release Manager
>
> To: dev@amaterasu.incubator.apache.org
>
> Subject: [VOTE] Release 1.2.3, release candidate #3
>
>
> Hi everyone,
>
> Please review and vote on the release candidate #3 for the version 1.2.3,
> as follows:
>
> [ ] +1, Approve the release
>
> [ ] -1, Do not approve the release (please provide specific comments)
>
>
>
> The complete staging area is available for your review, which includes:
>
> * JIRA release notes [1],
>
> * the official Apache source release to be deployed to dist.apache.org [2],
> which is signed with the key with fingerprint FFFFFFFF [3],
>
> * all artifacts to be deployed to the Maven Central Repository [4],
>
> * source code tag "v1.2.3-RC3" [5],
>
> * website pull request listing the release and publishing the API reference
> manual [6].
>
> * Java artifacts were built with Maven MAVEN_VERSION and OpenJDK/Oracle JDK
> JDK_VERSION.
>
> * Python artifacts are deployed along with the source release to the
> dist.apache.org [2].
>
>
> The vote will be open for at least 72 hours. It is adopted by majority
> approval, with at least 3 PMC affirmative votes.
>
>
> Thanks,
>
> Release Manager
>
>
> [1] link
>
> [2] link
>
> [3] https://dist.apache.org/repos/dist/release/incubator-amaterasu/KEYS
>
> [4] link
>
> [5] link
>
> [6] link
> --------------------------------------------------------------------------------------
>
> === Mentors help needed
>
> Mentors, please elaborate on how the voting process should work for an
> incubating project.
>
> ======================================
>
>
> If there are any issues found in the release candidate, reply on the vote
> thread to cancel the vote. There’s no need to wait 72 hours. Proceed
> to the *Fix
> Issues* step below and address the problem. However, some issues don’t
> require cancellation. For example, if an issue is found in the website pull
> request, just correct it on the spot and the vote can continue as-is.
>
> If there are no issues, replay on the vote thread to close the voting.
> Then, tally the votes in a separate email. Here’s an email template; please
> adjust as you see fit.
> --------------------------------------------------------------------------------------
>
> From: Release Manager
>
> To: dev@amaterasu.incubator.apache.org
>
> Subject: [RESULT] [VOTE] Release 1.2.3, release candidate #3
>
>
> I'm happy to announce that we have unanimously approved this release.
>
>
> There are XXX approving votes, XXX of which are binding:
>
> * approver 1
>
> * approver 2
>
> * approver 3
>
> * approver 4
>
>
> There are no disapproving votes.
>
>
> Thanks everyone
>
> --------------------------------------------------------------------------------------
>
> Checklist to proceed to the finalization step:
>
> 1. Community votes to release the proposed candidate, with at least
> three approving IPMC votes
>
> === Fix any issues ===
>
> Any issues identified during the community review and vote should be fixed
> in this step.
>
> Code changes should be proposed as standard pull requests to the
> *master* branch
> and reviewed using the normal contributing process.
>
> For standard releases, this should be enough because during the release
> process, committers should avoid merging non-related PRs to master. and a
> new version branch should be created from the *master* branch.
>
> However, if non-related PRs ware merged or the release is from a release
> branch, relevant changes should be cherry-picked into the release branch.
> The cherry-pick commits should then be proposed as the pull requests
> against the release branch, again reviewed and merged using the normal
> contributing process.
>
> Once all issues have been resolved, you should go back and build a new
> release candidate containing these changes.
>
> Checklist to proceed to the finalization step:
>
>
> 1. Issues identified during vote have been resolved, with fixes
> committed to the release branch.
>
> === Finalize the release ===
>
> Once the release candidate has been reviewed and approved by the community,
> the release should be finalized. This involves creating a release branch
> which is the same procedure as building an RC branch with the sole
> difference of not having the _rc suffix.
>
> === Promote the release ===
>
>
> Once the release has been finalized, the last step of the process is to
> promote the release within the project and beyond.
>
> ==== Apache Mailing Lists ===
>
> Announce on the dev@ mailing list that the release has been finished.
>
> Announce on the release on the general@incubator.apache.org mailing list,
> listing major improvements and contributions.
>
> Announce the release on the announce@apache.org mailing list.
> ==== Amaterasu Blog ====
>
> Major or otherwise important releases should have a blog post. Write one if
> needed for this particular release. Minor releases that don’t introduce new
> major functionality don’t necessarily need to be blogged.
> ==== Social Media ====
>
> Tweet, post on Facebook, LinkedIn, and other platforms. Ask other
> contributors to do the same.
>
> Checklist to proceed to the finalization step:
>
> 1. Release announced on the dev@ mailing list.
> 2. A blog post published, if applicable.
> 3. Release recorded in reporter.apache.org.
> 4. Release announced on social media.
> 5. Completion declared on the general@incubator.apache.org mailing list.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com