...

End of rampdown is code freeze. Code freeze is based on dates, but the actual time of freeze is determined by announcing.

P3. Stabilization

During the stabilization phase, only blockers are accepted. Usually it Including anything to the release should be approval of approved by the release manager to for each commit.

Note blockers defined here is not only a as any 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 (building release candidate)

Once all changes are applied, it is possible to prepare a release candidate.

4.0. Prepare Release Notes

...

4.0.2. Optionally you may ask for a review of resulting release notes on the list.

4.0.3. Update RELEASE_NOTES.txt and commit Release Notes changes into master and a release branch.

4.1. Update release branch versions and year in copyright messages

4.1.1. Update version in the release branch (execute the script from Ignite project root directory, you can use WSL or GitBash on Windows): 

./scripts/update-versions.sh 2.7.56

 and commit changes. This step is important is essential for release because later the source code will be published into SVN. For the code version Version update is required to be committed before RC building.

4.1.2. Double-check that year in copyright messages is correct. If the release is minor and based on an older branch, this branch can contain an outdated value of the year. Fix if needed. Example commit of updating year.

4.1.3. (Not actual since 2.8, there is the feature for an auto-generating year). Update copyright year manually in IgniteVersionUtils

4.2. Prepare RC on Teamcity

...