THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Page History
| Table of Contents |
|---|
Introduction
Following picture demonstrates release stages sequence.
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
P0. Initializing
Release phases dates are discussed, as release manager during the first discussion. Release Manager should be PMC Member.
Moving scope freeze and code freeze dates maybe not the best option since a lot of contributors synchronize their efforts to make feature completed by particular moment.
See also Release manager Notes; it contains some instructions for a release manager.
P1.1 Implementation and Scope Discussion
Difference between this and the following phase: it is not possible to move in-progress tickets to a next release because branches not diverged.
New branch creation moment is not formal, and it can happen just before or simultaneously with scope freeze. The important thing is announcing this moment and reminding contributors to cherry-pick commits to release branch.
P1.2 Implementation and Scope Finalization
Once release manager found, he/she can setup environment.
Prerequisites for release manager
0.1. Write access to Apache Ignite GIT & SVN repository (commiter role) - https://gitbox.apache.org/repos/asf?p=ignite.git
0.2. Access to Team City Release tasks - https://ci.ignite.apache.org/project.html?projectId=ApacheIgniteReleaseJava8 If you don't have necessary rights ask for assigning on dev. list.
0.3.Your GPG key available in https://apache.org/dist/ignite/KEYS - Steps to add:
| Expand | ||||
|---|---|---|---|---|
Following setup is performed only once. Check README.txt from https://github.com/apache/ignite-release/tree/master/scripts This readme file contains some additional requirement and setup steps. 0.3.1. If you don’t have your Apache key set up, please see https://www.apache.org/dev/openpgp.html#home on how to generate a new key. Steps to be followed:
0.3.2. Export key to Apache SVN. See section 'Create/Import your pgp secret key' in Readme.txt in https://github.com/apache/ignite-release/tree/master/scripts
Steps to be followed:
0.3.3. Export the key to a Public Key Server To publish key follow instructions from https://www.apache.org/dev/openpgp.html#publish-in-web-space You may use
alternatively, you - can export key to an .asc file (gpg --armor --export 6F6F6F6F > key.asc) - and submit the key file content manually to a public key server. For example, at MIT server you can just paste asc file content to a text field and submit: to http://pgp.mit.edu/ or to http://keyserver.ubuntu.com/ |
P1. Scope development and implementation
P1.1 Implementation and Scope Discussion
Difference between this and the following phase: it is not possible to move in-progress tickets to a next release because branches not diverged.
New branch creation moment is not formal, and it can happen just before or simultaneously with scope freeze. The important thing is announcing this moment and reminding contributors to cherry-pick commits to release branch.
P1.2 Implementation and Scope Finalization
Removing issues from the scope based on estimated dates of completion, importance to release and on community discussion. Private discussion between contributors is possible, but it is recommended to discuss features in public to allow all community members to share their arguments and concerns.
The first step to be done to enter scope finalization phase it to create a branch in Ignite code base (origin). This moment be precisely the same with the start of P1.1
1.2.1. Create release branch, e.g ignite-2.8, push it to the ASF repository
1.2.2. Run TC tests (on the appropriate branch), use https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAllNightly
1.2.3. Estimate state of TC, check failures history (if any).
1.2.4. Create scheduled build triggers for daily Run All (Nightly) run. Usually, triggers are set up using Apache Ignite TeamCity Bot (triggering of builds there depends on agent availability). Use an intellectual trigger to trigger release branch adaptively, or ask on the dev. list to addRemoving issues from the scope based on estimated dates of completion, importance to release and on community discussion. Private discussion between contributors is possible, but it is recommended to discuss features in public to allow all community members to share their arguments and concerns.
End of this phase is scope freeze.
P2. Rampdown
This phase is some time to complete implementation of features from the initial scope. In parallel with implementation, some less essential fixes and features are moved to the next release.
End of rampdown is code freeze. Code freeze is based on dates, but the actual time of freeze is determined by announcing.
P3. Stabilization
There only blockers are accepted. Usually it should be approval of release manager to each commit.
Note blockers here is not only a critical bug, but an issue in the product which makes product unstable or non-functioning, performance drop has proven by a benchmark, a security issue, or a regression of existing features.
P4. Vote preparation and Voting
Sending Release For Vote
After the community agrees that the codebase is ready for a release, release manager should send the release for a vote.
...
Overview
Content Tools
Apps