Excerpt |
---|
This page describes process and provides instructions to release manager on how to release Apache Ignite |
Table of Contents |
---|
...
Following picture demonstrates release stages sequence.
Gliffy Diagram | ||||
---|---|---|---|---|
|
Table of contents
Table of Contents |
---|
Release phases dates are discussed, as release manager during the first discussion. Release Manager should be PMC Member.
...
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/ |
...
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 as the start of P1.1
1.2.1. Create release branch, e.g ignite-2.8, push it to the ASF repository. (optional) consider creating PR for release, having PR is convenient because GitHub will notify you about commits to the branch.
1.2.2. Run TC tests (on the appropriate branch), use https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_RunAllNightly
...
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 add.
1.2.5. Create/schedule the nightly release build triggering – Releases Apache Ignite Nightly (may require TC permissions).
End of this phase is scope freeze.
...
This phase is some time to complete the 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 ramp-down is code freeze. Code freeze is based on dates, but the actual time of freeze is determined by announcing.
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
...
...
Gliffy Diagram | ||||||
---|---|---|---|---|---|---|
|
Once all changes are applied, it is possible to prepare a release candidate. It is possilbe to build several release candidates without starting a vote. First RCs can have part of changes scheduled for release.
4.0.1. Collect Release Notes (this step action is manual now). Check . Consider preparing HTML file in addition to text for future step 6.3.6. Check all completed tickets from the release page. Ticket may or may not have release notes, and this depends on if it is reasonable to mention change for users.
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.1. Update version in the release branch (execute script from Ignite project root directory):
No Format |
---|
./scripts/update-versions.sh 2.7.5 |
and commit changes. This step is important for release because later the source code will be published into SVN. For the code version update is required before RC building.
4.2.1. Run [RELEASES] Apache Ignite / Main [1] Release Build for ignite-x.y or for ignite-x.y.z. branch. You will need to enter version number (value if x.y.0 or x.y.z), and specify release candidate number. For testing purposes it is recommended to use rc0. You may several times re-build same rc- number.
4.2.2.Download and unzip release archive. It can be found at "Artifacts" tab on build page. Example:
...
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
~/download:[]$ unzip release-2.7.0-rc0.zip |
Update version in the release branch (execute the script from Ignite project root directory, you can use WSL or GitBash on Windows):
No Format |
---|
./scripts/update-versions.sh 2.7.6 |
and commit changes. This step is essential for release because later the source code will be published into SVN. Version update is required to be committed before RC building.
In the release branch, open the docs/_config.yml file and update the version property with the release number.
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.
Following step is not actual since 2.8, there is the feature for an auto-generating year: Update copyright year manually in IgniteVersionUtils
Version of packages update is not automated since it requires to add verison to history to update it. Update is more or less similar to this commit
No Format |
---|
apache-ignite (2.7.6-1) unstable; urgency=low
* Updated Apache Ignite to version 2.7.6
-- Petr Ivanov <mr.weider@gmail.com> Wed, 20 Aug 2019 20:58:44 +0300 |
Check dates are correct, and version is postfixed with '-1' - it is package version number, it is required by format
No Format |
---|
Name: |
4.2.3. Write down build number (Teamcity identification of builds). This number will be re-used in a future steps.
Run vote scripts to prepare RC before voting. You may skip steps 4.3.1 & step 4.3.2 in case you want to run some testing of release. In case release build it made for testing purposes, go to step 3 in this section.
Run script vote_1[git]create_rc_tag.sh Example of script output:
Expand | ||||
---|---|---|---|---|
Code Block | | |||
|
Please, check corresponding git tag is created and is available in ASF repository: https://gitbox.apache.org/repos/asf?p=ignite.git;a=tags
Note: If you've already uploaded staging, you should remove it from nexus - https://repository.apache.org/#stagingRepositories
Run script ./vote_2\[mvn\]\[pgp\]deploy_to_staging.sh Example of script output:
apache-ignite
Version: 2.7.6 |
and add lines similar to following after change log
No Format |
---|
* Fri 20 Aug 2019 Peter Ivanov <mr.weider@gmail.com> - 2.7.6-1
- Updated Apache Ignite to version 2.7.6 |
Make sure dates are correct, add package build number, '-1' at the end of package version.
4.2.3.3. (optional) ask for review on the list.
4.2.3.4. Commit package version changes into master and a release branch.
Run [RELEASES] Apache Ignite / Main [1] Release Build for ignite-x.y or for ignite-x.y.z branch. You will need to enter version number (value if x.y.0 or x.y.z), and specify release candidate number. For testing purposes, it is recommended to use rc0. You may several times re-build same rc- number.
Download and unzip release archive. It can be found at "Artifacts" tab on build page. Example:
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
Go to Nexus UI https://repository.apache.org/#stagingRepositories, login using Apache credentials and close repository. Close is a heavy background process, which makes repository visible for others. Provide some comment for closing repository, e.g. `Repository for Apache Ignite 2.7.5 - RC2`. After some time check if repository was closed successfully.
? Probably this build step was migrated to TC and automated ?
...
Run script ./vote_3_step_1\[packages\]build.sh . Example of output:
...
Code Block | ||||
---|---|---|---|---|
| ||||
$ ./vote_3_step_1\[packages\]build.sh
...
dpkg-deb: building package 'apache-ignite' in '../apache-ignite_2.7.0-1_all.deb'.
copied '/tmp/tmp.rEePHrMMWU/apache-ignite_2.7.0-1_all.deb' -> '/home/dragon/download/release/packaging/apache-ignite_2.7.0-1_all.deb'
удалён '/tmp/tmp.rEePHrMMWU/apache-ignite_2.7.0-1_all.deb'
Removing temporary work directories: /tmp/tmp.rEePHrMMWU
=== Run time: 0h:00m:36s ===
packaging/apache-ignite-2.7.0-1.noarch.rpm:
Processing packaging/apache-ignite_2.7.0-1_all.deb...
gpg: все значения, переданные в '--default-key', игнорируются
Signed deb packaging/apache-ignite_2.7.0-1_all.deb
mkdir: создан каталог 'packaging/pkg'
renamed 'packaging/apache-ignite-2.7.0-1.noarch.rpm' -> 'packaging/pkg/apache-ignite-2.7.0-1.noarch.rpm'
renamed 'packaging/apache-ignite_2.7.0-1_all.deb' -> 'packaging/pkg/apache-ignite_2.7.0-1_all.deb' |
Run script vote_3_step_2[pgp]sign_artifacts.sh . Example of script output
...
Code Block | ||||
---|---|---|---|---|
| ||||
$ ./vote_3_step_2\[pgp\]sign_artifacts.sh
# Starting GPG Agent #
Signing ./svn/vote/apache-ignite-fabric-2.7.0-bin.zip
Signing ./svn/vote/apache-ignite-2.7.0-src.zip
Signing ./svn/vote/apache-ignite-hadoop-2.7.0-bin.zip
Signed OK.
===============================================
Artifacts should be signed
Please check results at ./svn/vote
Each file should have corresponding *.asc file
NOTE: Package files are not signed because they
are meant to be stored in Bintray |
|
Do some checks related to release (full list of check to be done can be found in section 5.1):
Run vote scripts to prepare RC before voting. You may skip steps 4.4.1 & step 4.4.2 in case you want to run some testing of release. In case release build was made for testing-only purposes, you can go to step 4.4.3 in this section.
Run script vote_1[git]create_rc_tag.sh Example of script output:
Expand | |||||||
---|---|---|---|---|---|---|---|
|
Please, check corresponding git tag is created and is available in ASF repository: https://gitbox.apache.org/repos/asf?p=ignite.git;a=tags
Note: If you've already uploaded staging, you should remove it from nexus - https://repository.apache.org/#stagingRepositories
Run script ./vote_2\[mvn\]\[pgp\]deploy_to_staging.sh Example of script output:
Expand | |||||||
---|---|---|---|---|---|---|---|
|
Go to Nexus UI https://repository.apache.org/#stagingRepositories, log in using Apache credentials and close repository.
Provide some comment for closing repository, e.g. `Repository for Apache Ignite 2.7.6 - RC0`.
Close is a heavy background process, which makes repository visible for others. After some time, check if the repository closed successfully and visible.
Once repository is closed, write down a link to content, e.g. https://repository.apache.org/content/repositories/orgapacheignite-1464/ This link is useful for vote thread and sharing with others, who is going to test RC.
Pre-build packages can be found at 'release-2.7.6-rc0\packages' folder of release candidate archive.
Building packages locally supported only on Linux, WSL not supported. Steps to build from scratch (optionally):
Expand |
---|
Note: The following script is locale-specific. You should execute it on the en locale Run script ./vote_3_step_1\[packages\]\[optional\]build.sh . Example of output: |
Please check results at ./svn/vote. Optionally you may also check hash/sign using https://www.apache.org/info/verification.html
Run scrupt vote_3_step_3[svn]deploy_artifacts.sh Example of output:
|
Check binaries and sources are available in the SVN: https://dist.apache.org/repos/dist/dev/ignite/
Compare with previous release.
...
To start the build you need to specify current (staging) version and released version of Apache Ignite. See "Artifacts" tab to get task results. Example:
...
For 2.7 release "apache-ignite-hadoop" removed and some new dependencies introduced for a benchmarks.
Using Teamcity build number from step 4.2.1, run https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_PrepareVote3BuildNuGetPackages
This will produce .nupkg files as build artifcats, and push the packages to https://www.myget.org/F/apache-ignite-staging/ for easier testing.
After the community agrees that the codebase is ready for a release, release manager should send the release for a vote.
The email subject should be "[VOTE] Release Apache Ignite <version> <rc>", e.g. "[VOTE] Release Apache Ignite 2.7.5 RC4".
Vote email should include reference that vote is formal and votes meaning for +1,0,-1.
Here is the sample email:
...
Code Block | ||
---|---|---|
| ||
Dear Community,
We have uploaded release candidate to
https://dist.apache.org/repos/dist/dev/ignite/2.7.5-rc3/
The following staging can be used for a dependent project for testing:
https://repository.apache.org/content/repositories/orgapacheignite-1438/
This is very important release containing initial versions of Ignite.NET
and Ignite C++ and many other important features.
Tag name is
1.5.0.final-rc3
1.5.0 changes:
* Ignite.NET: Initial Release.
* Ignite C++: Initial Release.
* Massive performance improvements for cache operations and SQL.
* Added new binary cache object marshalling implementation.
* Added IgniteSemaphore data structure.
* Added MQTT Streamer.
* Added Twitter Streamer.
* Added Ignite Sink (integration with Apache Flume).
* Fixed optimistic serializable transactions: implemented "deadlock-free"
locking algorithm.
* Fixed failover for continuous queries.
* Fixed compilation and runtime errors under OpenJDK and IBM JDK.
* Fixed Integer.size limitation for cache.
* Fixed and improved cache types configuration.
* Fixed cache rebalancing.
* Many stability and fault-tolerance fixes.
* Added example to demonstrate the usage of EntryProcessor.
Complete list of closed issues:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20IGNITE%20AND%20fixVersion%20%3D%201.5%20AND%20status%20%3D%20closed
DEVNOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=DEVNOTES.txt;hb=refs/tags/1.5.0.final-rc3
RELEASENOTES
https://git-wip-us.apache.org/repos/asf?p=ignite.git;a=blob_plain;f=RELEASE_NOTES.txt;hb=refs/tags/1.5.0.final-rc3
The vote is formal, see voting guidelines https://www.apache.org/foundation/voting.html
+1 - to accept Apache Ignite 1.5.0.final-rc3
0 - don't care either way
-1 - DO NOT accept Apache Ignite 1.5.0.final-rc3 (explain why)
This vote will be open for 72 hours till May 23, 14:00 UTC.
https://www.timeanddate.com/countdown/to?year=2019&month=5&day=23&hour=14&min=0&sec=0&p0=utc-1 |
Examples of Voting threads Vote on 2.7.5; Vote on 2.7.0
Optionally you can create a separate discussion for questions related to RC: Discussion on 2.7.5
All community members are encouraged to verify release. PMC members have a binding vote, but each vote matters.
Following list are steps, which can be done by each member, see also https://www.apache.org/info/verification.html
It is not complete list, community members can test any module or feature of the product.
Check that all JIRA issues for the specific version are Closed (example JQL: `project = IGNITE AND fixVersion <= 1.7 AND status != closed`).
Code Block | ||
---|---|---|
| ||
curl "https://issues.apache.org/jira/rest/api/2/search?jql=project=ignite%20AND%20status%20!=%20closed%20AND%20fixVersion<=1.7&fields=summary" | grep '"total":0,"issues":\[\]' |
|
Build script will sign artifacts automatically (in case of build locally), but TC pre-build packages need to be signed by release manager key.
Find your public key ID by running
No Format |
---|
gpg --list-keys |
Key Id will look like as 16 hexadecimal, e.g., 612654F7; it is the same value from step 0.3.2.
Sing RPM pre-build package by command
No Format |
---|
rpm --define "_gpg_name 612654F7" --addsign packages/pkg/*.rpm
Enter pass phrase:
Pass phrase is good.
packages/pkg/apache-ignite-2.7.5-1.noarch.rpm: |
Sign DEB pre-build package by command
No Format |
---|
dpkg-sig -k 612654F7 --sign builder packages/pkg/*.deb
Processing packages/pkg/apache-ignite_2.7.5-1_all.deb...
You need a passphrase to unlock the secret key for
user: "Apache User (CODE SIGNING KEY) <login@apache.org>"
4096-bit RSA key, ID 612654F7, created 2019-03-19
Signed deb packages/pkg/apache-ignite_2.7.5-1_all.deb |
You can validate that file modification time was changed after singing.
Run script vote_3_step_2[pgp]sign_artifacts.sh . Example of script output
Expand | |||||||
---|---|---|---|---|---|---|---|
|
Please check results at ./svn/vote. Optionally you may also check hash/sign using https://www.apache.org/info/verification.html
Run script vote_3_step_3[svn]deploy_artifacts.sh. This script will upload your local artifacts to a a development area under e.g. https://dist.apache.org/repos/dist/dev/2.7.0-rc0
which is used for staging releases candidates.
Each ASF committer has a write access to this area – WHERE CAN I STAGE A RELEASE CANDIDATE?
Example of output:
Expand | |||||||
---|---|---|---|---|---|---|---|
|
Check binaries and sources are available in the SVN: https://dist.apache.org/repos/dist/dev/ignite/
There is TC task for generating report containing difference comparing current release with previous.
https://ci.ignite.apache.org/viewType.html?buildTypeId=ApacheIgniteReleaseJava8_IgniteRelease72CheckFileConsistency
You should run it and do sanity check for a changed files.
To start the build you need to specify current (staging) version and released version of Apache Ignite. See "Artifacts" tab to get task results. Example:
Expand |
---|
For 2.7 release "apache-ignite-hadoop" removed and some new dependencies introduced for a benchmarks. |
Run '[3] Apache Ignite Release Vote | Check RC' https://ci.ignite.apache.org/buildConfiguration/ApacheIgniteReleaseJava8_PrepareVote4CheckRcLicensesChecksum
This step will validate hashes, Javadoc, build from sources, licenses. So it it required to run it to simplify/skip some local checks from section 5.1.
Expand |
---|
After the community agrees that the codebase is ready for a release, release manager should send the release for a vote.
The email subject should be "[VOTE] Release Apache Ignite <version> <rc>", e.g. "[VOTE] Release Apache Ignite 2.7.5 RC4".
Vote email should include reference that vote is formal and votes meaning for +1,0,-1.
Here is the sample email:
Expand | |||||
---|---|---|---|---|---|
|
Examples of Voting threads Vote on 2.7.5; Vote on 2.7.0
Optionally you can create a separate discussion for questions related to RC: Discussion on 2.7.5
All community members are encouraged to verify release. PMC members have a binding vote, but each vote matters.
The following list are steps, which can be done by each member, see also https://www.apache.org/info/verification.html
It is not a complete list, community members can test any module or feature of the product.
Check that all JIRA issues for the specific version are Closed (example JQL: `project = IGNITE AND fixVersion <= 1.7 AND status != closed`).
Code Block | ||
---|---|---|
| ||
curl "https://issues.apache.org/jira/rest/api/2/search?jql=project=ignite+AND+status+!=+closed+AND+fixVersion<=1.7&fields=summary" | grep '"total":0,"issues":\[\]' |
Check that sha512 checksum is correct.
Code Block | ||
---|---|---|
| ||
sha512sum -c *.sha512 |
Check that signature is correct.
Code Block | ||
---|---|---|
| ||
gpg --verify-files *.asc |
Check licenses from the source code.
Code Block | ||
---|---|---|
| ||
mvn clean validate -DskipTests=true -P check-licenses |
Build the binary releases from the source code.
Code Block | ||
---|---|---|
| ||
mvn clean package -DskipTests |
Build Ignite.NET binaries and NuGet packages
Code Block | ||
---|---|---|
| ||
cd modules\platforms\dotnet
build -skipJava |
See also Incubator Release Checklist for more checks.
In case there is -1 vote present (it is not a veto, even if it was casted by PMC), release manager has ultimate rigth to cancel vote immediately to fix related issues.
Usually +1 means that community member agrees that current release is better with previous.
Usually with +1 member shares which checks were done.
Vote should be open for at least 72hours. In case insufficient votes are available vote can be kept open as long as it needed without additional announce. But in this case release manager has option to close the vote as unsuccessfull in case time is out.
Info |
---|
Whenever consensus cannot be reached, standard Apache Voting Process will be used to reach a solution. |
Send an email with subject "[RESULT] <vote subject>" ("[RESULT] [VOTE] Release Apache Ignite <version> (<rc>)") and provide vote results: if it passes or not, provide voting details.
For example, "[RESULT] [VOTE] Release Apache Ignite 2.7.5 (RC1)" and body similar to 2.7.5 vote result, 2.7.0 vote result . See also other example:
Expand | |||||
---|---|---|---|---|---|
|
In case vote is unsuccessful or closed by release manager, prepare new release candidate with fixes starting from step 4.2
In case vote was sucessfull, run release* scripts from release candidate local home from step 4.2.1.
Run release_1[svn]move_binaries.sh (Note: Only PMC members have write access to the release repository). Example of output
Expand | |||||||
---|---|---|---|---|---|---|---|
|
Check that sha1 & md5 checksum is correct.
Code Block | ||
---|---|---|
| ||
sha1sum -c *.sha1
md5sum -c *.md5 |
Check that signature is correct.
Code Block | ||
---|---|---|
| ||
gpg --verify-files *.asc |
...
Check licenses from the source code.
Code Block | ||
---|---|---|
| ||
mvn clean validate -DskipTests=true -P check-licenses |
Build the binary releases from the source code.
Code Block | ||
---|---|---|
| ||
mvn clean package -DskipTests -Dignite.edition=hadoop
mvn clean package -DskipTests |
Build Ignite.NET binaries and NuGet packages
Code Block | ||
---|---|---|
| ||
cd modules\platforms\dotnet
build -skipJava |
...
See also Incubator Release Checklist for more checks.
In case there is -1 vote present (it is not a veto, even if it was casted by PMC), release manager has ultimate rigth to cancel vote immediately to fix related issues.
Usually +1 means that community member agrees that current release is better with previous.
Usually with +1 member shares which checks were done.
Vote should be open for at least 72hours. In case insufficient votes are available vote can be kept open as long as it needed without additional announce. But in this case release manager has option to close the vote as unsuccessfull in case time is out.
Info |
---|
Whenever consensus cannot be reached, standard Apache Voting Process will be used to reach a solution. |
Send an email with subject "[RESULT] <vote subject>" ("[RESULT] [VOTE] Release Apache Ignite <version> (<rc>)") and provide vote results: if it passes or not, provide voting details.
For example, "[RESULT] [VOTE] Release Apache Ignite 2.7.5 (RC1)" and body similar to 2.7.5 vote result, 2.7.0 vote result . See also other example:
...
Code Block | ||
---|---|---|
| ||
Hello!
Apache Ignite 1.4.0 release (RC1) has been accepted.
9 "+1" votes received.
Here are the votes received:
- Denis Magda (binding)
- Anton Vinogradov (binding)
- Alexey Kuznetsov (binding)
- Sergi Vladykin (binding)
- Gianfranco Murador (binding)
- Vladimir Ozerov (binding)
- Raul Kripalani (binding)
- Konstantin Boudnik (binding)
- Chandresh Pancholi
Here is the link to vote thread -
http://apache-ignite-developers.2346864.n4.nabble.com/VOTE-Apache-Ignite-1-4-0-Release-RC1-tp3474.html
Ignite 1.4.0 successfuly released to https://dist.apache.org/repos/dist/release/ignite/1.4.0/
Thanks! |
In case vote is unsuccessful or closed by release manager, prepare new release candidate with fixes starting from step 4.2
In case vote was sucessfull, run release* scripts from release candidate local home from step 4.2.1.
Run release_1[svn]move_binaries.sh Example of output
...
Code Block | ||||
---|---|---|---|---|
| ||||
$ ./release_1\[svn\]move_binaries.sh
# Releasing 2.7.5-rc4 :: Binaries #
Committing transaction...
Committed revision 34469.
=========================================================
Artifacts should be moved to Apache Ignite's release site
Please check results at:
* binaries: https://apache.org/dist/ignite/2.7.5 |
Manual alternative of this script is move release to https://dist.apache.org/repos/dist/release/ignite/<version>
Code Block | ||
---|---|---|
| ||
svn mv https://dist.apache.org/repos/dist/dev/ignite/<version><rc> https://dist.apache.org/repos/dist/release/ignite/<version> -m "Release <version>" |
Result should be available at https://dist.apache.org/repos/dist/release/ignite/
Please check results at:
* binaries: https://apache.org/dist/ignite/{version}
There can be some sync lag with moving files and availability at https://apache.org/dist/ignite/
During running script you will be asked for bintray credentials to upload. Ask Infra to provide
Run script release_2[bintray]upload_packages.sh, example of output
...
Code Block | ||||
---|---|---|---|---|
| ||||
$ ./release_2\[bintray\]upload_packages.sh
# Releasing 2.7.5-rc4 :: Packages #
Please, enter credentials for accessing Bintray RPM repository
Username: |
Run Script release_3[svn]deploy_docs_to_site.sh
This script will unzip and upload file by file to SVN related to Apache Ignite site. This may take several minutes to complete. You may need to enter Apache credentials for committing changes. Example of execution:
...
Code Block | ||||
---|---|---|---|---|
| ||||
$ ./release_3\[svn\]deploy_docs_to_site.sh
# Releasing 2.7.5-rc4 :: Packages #
/// list of files///
Uploading to svn ...
Authentication realm: <https://svn.apache.org:443> ASF Committers
Password for 'dpavlov': ....
/// list of files///
Documentation should be uploaded to site repository
Please check results at
https://svn.apache.org/repos/asf/ignite/site/trunk/releases |
This step can be done manually
Upload documentation to https://svn.apache.org/repos/asf/ignite/site/trunk/releases/<version>
Code Block | ||
---|---|---|
| ||
svn import apache-ignite-fabric-<version>-bin/docs https://svn.apache.org/repos/asf/ignite/site/trunk/releases/<version> -m "new Release (<version>)" |
Check results availability at https://svn.apache.org/repos/asf/ignite/site/trunk/releases
Run script release_4[git]create_release_tag.sh Example of output
Expand | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
This step can be done manually : Create Release tag from RC tag
|
Please check results at https://gitbox.apache.org/repos/asf?p=ignite.git;a=tags
Release maven staging (https://maven.apache.org/developers/release/maven-project-release-procedure.html).
Go to Nexus UI https://repository.apache.org/#stagingRepositories, login using Apache credentials and release repository for accepted release candidate. You can release it by pressing the Release button (provided that you have successfully closed the staging repository).
This will move the components into the release repository of OSSRH where it will be synced to the Central Repository (see also https://central.sonatype.org/pages/releasing-the-deployment.html#close-and-drop-or-release-your-staging-repository)
The sync into Maven Central central staging from repository.apache.org occurs every 4 hours. There is a separate hourly schedule that runs which pushes from staging to the other central machines, and then updates the indexes.
Execute script from Ignite project root directory, this will update version in the master branch :
No Format |
---|
./scripts/update-versions.sh 2.9.0-SNAPSHOT |
and commit changes. This step is not required if minor release was issued,e.g. 2.7.5
Release all the documentation (Java, .NET, C++, etc.) on https://apacheignite.readme.io/docs
If you don't have persmission to edit docs, request permissions on the dev.list. If you get permissions go to admin panel https://dash.readme.io/nite.
Select project, find versions dropdown, select 'Manage versions'.
If verison is not created before: Click 'Create version', enter release number, prefix 'v' is not required. During process of creation you will be asked which version is to be used as base (fork) version. Enter version base release there.
If version exists, click to main version.
Repeat this process for all documentation projects for Ignite: Java, C#/.NET, C++, SQL, Integrations*, Ignite for Spark, Tools. Create version
Update the latest doc reference on ignite.apache.org:
Checkout SVN repository for Apache Ignite site: https://svn.apache.org/repos/asf/ignite/site/trunk
For speed up this operation make sure to limit branches in checkout operation.
Just copy-paste latest release notes from previous release, replace text formatting with headers, lists items.
Place these notes to corresponding release folder, for example releases/2.7.5. If folder is absent, check results of step 6.2.3.
Commit changes. File should be available on the site automatically.
To update https://ignite.apache.org with new download links.
Update https://svn.apache.org/repos/asf/ignite/site/trunk/download.html
Also make sure to use [preferred]/[distdir] and [disturl]/[distdir] for latest release.
Replace dist url to archive url for previous release. For example href="[preferred]/[distdir]/2.7.0/apache-ignite-2.7.0-src.zip" => href="https://archive.apache.org/dist/ignite/2.7.0/apache-ignite-2.7.0-src.zip"
Commit changes, check result at https://ignite.apache.org/download.cgi
Check provided links work fine.
Find `latest` text file in SVN repository for Apache Ignite site.
Update Ignite version in this file. Commit changes and check result at https://ignite.apache.org/latest
Go to JIRA project administration, select Apache Ignite, select Versions, select appropriate version and select Actions->Release.
Todo: add description of steps ?
Prepare the cloud images and update links to them here https://ignite.apache.org/download.cgi#docker. In addition, update the links to the images on the following documentation pages whenever is needed:
Todo add description of the step ?
Update Web Console docker image: https://hub.docker.com/r/apacheignite/web-console-standalone/tags/
Delete previous releases from https://dist.apache.org/repos/dist/release/ignite/..., replace their download URLs by https://archive.apache.org/dist/ignite/...
Retrieve all .nupkg files from build artifacts of step 4.5
You many need to install client tools for .NET https://docs.microsoft.com/en-us/nuget/install-nuget-client-tools (download file & add it to PATH). You can use nuget.exe 4.x version (because NuGet.exe 5.0 and later require .NET Framework 4.7.2 ).
...
You can find configuration file under user home directory, for example, on Windows
No Format |
---|
cd %appdata%\Nuget |
Example of configuration:
Code Block | ||
---|---|---|
| ||
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
<config>
<add key="defaultPushSource" value="https://nuget.org/" />
</config>
</configuration> |
Manual alternative of this script is move release to https://dist.apache.org/repos/dist/release/ignite/<version>
|
Result should be available at https://dist.apache.org/repos/dist/release/ignite/
Please check results at:
* binaries: https://apache.org/dist/ignite/{version}
There can be some sync lag with moving files and availability at https://apache.org/dist/ignite/
During running script you will be asked for auth API key to upload. Login to the https://apache.jfrog.io/ui/ with Apache ID credentials and get the API key from the authentication settings.
Run script release_2[bintray]upload_packages.sh, example of output
Expand | |||||||
---|---|---|---|---|---|---|---|
|
Run Script release_3[git]deploy_docs_to_site.sh
This script will checkout ignite-website from GIT, copy API documentation, and push changes back.
Check results availability at https://gitbox.apache.org/repos/asf?p=ignite-website.git;a=tree;f=releases;hb=refs/heads/master
Run script release_4[git]create_release_tag.sh Example of output
Expand | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
This step can be done manually : Create Release tag from RC tag
|
Please check results at https://gitbox.apache.org/repos/asf?p=ignite.git;a=tags
Release maven staging (https://maven.apache.org/developers/release/maven-project-release-procedure.html).
Go to Nexus UI https://repository.apache.org/#stagingRepositories, login using Apache credentials and release repository for accepted release candidate. You can release it by pressing the Release button (provided that you have successfully closed the staging repository).
This will move the components into the release repository of OSSRH where it will be synced to the Central Repository (see also https://central.sonatype.org/pages/releasing-the-deployment.html#close-and-drop-or-release-your-staging-repository)
The sync into Maven Central central staging from repository.apache.org occurs every 4 hours. There is a separate hourly schedule that runs which pushes from staging to the other central machines, and then updates the indexes.
Execute the script from Ignite project root directory, this will update version in the master branch :
No Format |
---|
./scripts/update-versions.sh 2.9.0-SNAPSHOT |
and commit changes. This step is not required if minor release was issued,e.g. 2.7.5
The dependency of ignite-extensions must be updated according to the new version in the master branch.
See the example below:
Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key IGNITE-13993
Publish the technical documentation on the website: How to Document - Publishing to the website
Checkout GIT repository for Apache Ignite site: https://gitbox.apache.org/repos/asf/ignite-website.git
Just copy-paste latest release notes from previous release, replace text formatting with headers, lists items.
Place these notes to corresponding release folder, for example releases/2.7.5. If folder is absent, check results of step 6.2.3.
Commit and push changes. File should be available on the site automatically.
Once the new release is published to dist.apache.org/release wait a day or so for mirrors to catch up.
After the release was propagated across all the mirrors, update the "Source Releases" and "Binary Releases" sections of the website downloads page:
Find `latest` text file in GIT repository for Apache Ignite site.
Update Ignite version in this file. Commit changes and check result at https://ignite.apache.org/latest
Go to JIRA project administration, select Apache Ignite, select Versions, select appropriate version and select Actions->Release.
This section Intended for preparing a docker image for https://apacheignite.readme.io/docs/docker-deployment
Prerequisite: Docker installed. For example, for Windows you can download https://docs.docker.com/docker-for-windows/ You may need to register at docker hub.
Credentials can be found in SVN:
https://svn.apache.org/repos/private/pmc/ignite/credentials/hub.docker.com.txt (PMC only)
You can get a binary distribution from the 'vote' folder of the release candidate.
Follow instructions from the README file and Dockerfile are available at:
https://github.com/apache/ignite/tree/master/deliveries/docker/apache-ignite
To build images run the following commands (insert correct release number):
Code Block | ||
---|---|---|
| ||
docker build . -f ./x86_64/Dockerfile -t apacheignite/ignite:2.15.0 -t apacheignite/ignite:latest
docker build . -f ./x86_64/Dockerfile -t apacheignite/ignite:2.15.0-jdk11 --build-arg JDK_VERSION=11
docker build . -f ./s390x/Dockerfile -t apacheignite/ignite:2.15.0-jdk11-s390x --build-arg IGNITE_VER=2.15.0
docker buildx build . -f ./arm64/Dockerfile -t apacheignite/ignite:2.15.0-arm64 --push --platform linux/arm64
docker buildx build . -f ./arm64/Dockerfile -t apacheignite/ignite:2.15.0-jdk11-arm64 --push --platform linux/arm64 --build-arg JDK_VERSION=11 |
This build takes a distribution from some folder named like apache-ignite*
You can validate images created by calling
Code Block | ||
---|---|---|
| ||
docker images |
Run image to check it works well:
Code Block | ||
---|---|---|
| ||
docker run -it --rm --name apache-ignite <IMAGE> |
To publish image run
Code Block | ||
---|---|---|
| ||
docker login |
Run
Code Block | ||
---|---|---|
| ||
docker push apacheignite/ignite:2.15.0
docker push apacheignite/ignite:2.15.0-jdk11
docker push apacheignite/ignite:2.15.0-jdk11-s390x
docker push apacheignite/ignite:latest |
Check results at https://hub.docker.com/r/apacheignite/ignite
Todo: add description of steps ?
In addition, update the links to the images on the following documentation pages whenever is needed:
Todo: add description of steps ?
https://apacheignite.readme.io/docs/google-compute-deployment
Prepare the cloud images and update links to them here https://ignite.apache.org/download.cgi#docker.
Old releases should be archived. Delete previous releases from https://dist.apache.org/repos/dist/release/ignite/... (PMC only):
Code Block | ||
---|---|---|
| ||
svn rm -m "Archiving release X.Y.Z" https://dist.apache.org/repos/dist/release/ignite/X.Y.Z/ || true |
Replace their download URLs by https://archive.apache.org/dist/ignite/...
Delete unsucessfull release candidates and packages (if any) from dev section of Apache SVN repository https://dist.apache.org/repos/dist/dev/ignite/
Retrieve all .nupkg files from build artifacts of step 4.5
You may need to install client tools for .NET https://docs.microsoft.com/en-us/nuget/install-nuget-client-tools (download file & add it to PATH). You can use nuget.exe 4.x version (because NuGet.exe 5.0 and later require .NET Framework 4.7.2 ).
It may be required to configure nuget.exe using NuGet.Config(XML) https://docs.microsoft.com/en-us/nuget/tools/cli-ref-push for using nuget.org as default push source.You can find configuration file under user home directory, for example, on Windows
No Format |
---|
cd %appdata%\Nuget |
Configuration on Linux can be skipped. The push source is set up by -s param in the script.
Example of configuration:
Code Block | ||
---|---|---|
| ||
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
<config>
<add key="defaultPushSource" value="https://nuget.org/" />
</config>
</configuration> |
Credentials (API key to push packages) can be found in https://svn.apache.org/repos/private/pmc/ignite/credentials/nuget.org (PMC only, use Apache ID to login).
Windows, .NET Classic, PowerShell:
No Format |
---|
ls *.nupkg | % { nuget push $_.FullName API_KEY_HERE } |
Power shell example ouptput:
Expand | ||
---|---|---|
|
Credentials (API key to push packages) can be found in https://svn.apache.org/repos/private/pmc/ignite/credentials/nuget.org (PMC only, use Apache ID to login).
Windows, .NET Classic, PowerShell:
No Format |
---|
ls *.nupkg | % { nuget push $_.FullName API_KEY_HERE } |
Power shell example ouptput:
Expand | ||
---|---|---|
|
Linux, .NET Core, sh:
No Format |
---|
for i in *.nupkg; do dotnet nuget push $i -k API_KEY_HERE -s "https://nuget.org/"; done |
Check result at https://www.nuget.org
...
Packages become visible from UI with some delay (~5-10 minutes)>
Make sure that the artifacts were synced up to Maven Central. Refer to the recently happened issue (
) Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key INFRA-13073
Usually, this sync should be completed in 4 hours after releasing repository at step 6.3.1. If it is not released, contact infra.
Create a new issue to enforce compatibility checks and prepare the PR. Add the released version to the IgniteReleasedVersion enum. Ask for a review on dev-list if necessary.
Prepare a new blog post with the most major and meaningful release improvements.
Post this on - https://blogs.apache.org/ignite/ (ask Maxim Muzafarov or Denis Magda if there is any help required with the publication).
Linux, .NET Core, sh:
No Format |
---|
for i in *.nupkg; do dotnet nuget push $i -k API_KEY_HERE; done |
Check result at https://www.nuget.org/packages/Apache.Ignite/
Packages become visible from UI with some delay (~5-10 minutes)>
Make sure that the artifacts were synced up to Maven Central. Refer to the recently happened issue (
) Jira server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key INFRA-13073
Usually this sync should be comleted in 4 hours after releasing repository at step 6.3.1. If it is not released, contat infra.
...
Announce the release by sending a single message to announce@apache.org and Ignite's user/dev lists.
Please not note that the 'announce 'list is ASF-level list and not all subscribers are aware about of Apache Ignite. So it is recommended to include short description of projecta short description of the project and put the link to the post from the 6.4.0.
Only PMC and Committers are able to send to the 'announce list.
Refer to the examples below:
If release includes any fixes for security issue, then announce security vulnerabilities that were fixed in the release.
Follow the ASF process https://www.apache.org/security/committers.html.
If release includes any fixes for the security issue, then announce security vulnerabilities that were fixed in the release.
Follow the ASF process https://www.apache.org/security/committers.html.
Check with security@ignite.apache.org if there are any vulnerabilities.
In case there are changes in set of used cryptographic libraries (see Crypto Notice), it is required to update Export Matrix http://www.apache.org/licenses/exports/#matrix
Matrix is stored in ASF-level SVN: https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/licenses/exports/index.page/eccnmatrix.xml
Only VP, product can commit to matrix source. Ask VP, Ignite on a list to update.Check with security@ignite.apache.org if there are any vulnerabilities.
Tip |
---|
This page was merged from several sources contributed by Nikolay Izhikov, Anton Vinogradov ,Denis Magda , Dmitry Pavlov , Pavel Tupitsyn , Andrey Gura , Vladimir Ozerov Ozerov , Alexey Kuznetsov , Yakov Zhdanov, Ilya Murchenko |
There are several unresoved unresolved issues / open questions:
Warning |
---|
1. Can committer be release manager and upload artifacts provided that PMC will upload committer's key 3. Steps to be done for prepare RPM/DEB packages - step 4.3.3.1 4. Unclear how to release documenation on readme io - step 6.3.4 5. Unclear how to prepare Step 6. Unclear on how to prepare/update 6.3.10. Prepare cloud images6. Unclear how to prepare/update Web Console docker. Step 6.3.1111.GCE&AWSvirtualmachines 7. Steps to be done to upload RPM/DEB packages |