As an RM (release manager),The following items need to be completed:
(Note: This article serves as a practical guide for a new RM, so it does not explain "why this step is needed" for all steps)
This article makes extensive reference to the following tutorials:
- https://plc4x.apache.org/developers/release.html
- Tutorial for signing gpg
This article takes IoTDB as an example and introduces the process of IoTDB release from 0.8.0 to 0.8.1. This article is directly applicable to those projects that are managed using maven.
Contents:
Table of Contents | ||
---|---|---|
|
1. Create a gpg KEY
For those who are RM for the first time, this step needs to be carried out.
The requirements for creating gpg key are: use RSA key, and the length should be greater than 4096 bits.
How to achieve:
a. Install gpg2 software
MacOS: brew install gpg2
Run the following command to view the version
$ gpg2 --version
Note: Some people have gpg installed on their computers, which is consistent with gpg2. So for all subsequent commands, if gpg2 does not exist, use gpg instead; if gpg does not exist, use gpg2; if none exist, make sure you have at least one installed. .
b. Create key
Note that in this process, (1) the real name should be entered when entering the name; (2) the apache mailbox should be used when using the mailbox.
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
$ gpg2 --full-gen-key
gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 1
Note: Enter 1 here
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Note: Enter 4096 here
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 0
Note: Enter 0 here
Key does not expire at all
Is this correct? (y/N) y
Note: Enter y here
GnuPG needs to construct a user ID to identify your key.
Real name: your name
Note: Enter your name here
Email address: someone@apache.org
Note: Enter your email here
Comment: Apache IoTDB release signing key
Note: enter some comments here
You selected this USER-ID:
"your name (Apache IoTDB release signing key) <someone@apache.org>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
Note: Enter O here
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
|
Then a dialog box will pop up asking you to enter the key for this gpg. After the input is completed, it is created. The default file is located in the ~ / .gnupg directory.
My practice is located in a .rev file under: ~ / .gnupg / openpgp-revocs.d /
At the same time, the terminal will output: gpg: key a string of characters marked as ultimately trusted
Then check if this key avoids SHA-1:
Code Block | ||||
---|---|---|---|---|
| ||||
$ gpg2 --edit-key A string of numbers just now
gpg (GnuPG) 2.2.4; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
gpg: checking the trustdb
gpg: marginals needed: 3 completes needed: 1 trust model: pgp
gpg: depth: 0 valid: 2 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 2u
gpg: next trustdb check due at 2020-01-30
sec rsa4096/2206EF8F64C35889
created: 2019-09-25 expires: never usage: SC
trust: ultimate validity: ultimate
ssb rsa4096/2C8DBF57147E3901
created: 2019-09-25 expires: never usage: E
[ultimate] (1). your name (Apache IoTDB release signing key) <someone@apache.org>
gpg> showpref
Enter showpref here
[ultimate] (1). your name (Apache IoTDB release signing key) <someone@apache.org>
Cipher: AES256, AES192, AES, 3DES
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modify
If the order is different, you can adjust
gpg> setpref SHA512 SHA384 SHA256 SHA224 SHA1 AES256 AES192 AES 3DES ZLIB BZIP2 ZIP Uncompressed
Here, enter the three values of Digest Cipher Compression in order |
Note that as long as it is in the penultimate line, see Digest with SHA512 at the front and SHA1 at the end.(If you are interested in the reason for this modification, you can refer to:http://www.apache.org/dev/openpgp.html)
Be sure to remember your private key password, which will be used when releasing in the future!
c. Upload your key to a public server
$ gpg2 --keyserver pgp.mit.edu --send-keys <key id>
This <key id> is the file name of a .rev file under ~ / .gnupg / openpgp-revocs.d /
Next, check the link below to check if the upload was successful. It takes about a minute to find
Check the show full-key hashes under advance when checking
If the upload is not successful, you can manually submit the key on the web page
First export the public key in ASCII format
gpg2 --armor --output public-key.gpg --export "qiaojialin@apache.org"
The public-key.gpg file obtained is as follows:
Code Block |
---|
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQINBF2LLTABEACRM0lzt9BMSsIg9cCfcEBRH6Fc2etS7vrOt8NPq2VTuHYHUMzA
...
-----END PGP PUBLIC KEY BLOCK----- |
Next manually upload the above content, upload link http://keys.gnupg.net
You should be able to find it by now. . .
c.2 (Option)Look for the Committer in the Apache community you know to authenticate your public key
Reference link https://gist.github.com/F21/b0e8c62c49dfab267ff1d0c6af39ab84 It is mainly because the other party has something to do, so I will not explain it in detail.
d. Add your gpg public key to the KEYS file
This step requires the use of SVN. MacOS has installed SVN by default.
This article takes IoTDB 0.8.1 as an example when it has been released from 0.8.0.
d.1 Add the public key to KEYS in the dev branch to release the RC version
The svn library of the DEV branch is https://dist.apache.org/repos/dist/dev/incubator/iotdb
The SVN library of the release branch is https://dist.apache.org/repos/dist/release/incubator/iotdb
The command is as follows:
$ svn co https://dist.apache.org/repos/dist/dev/incubator/iotdb iotdb-dist-dev
This step is relatively slow, and all versions will be tested. If the network is disconnected, use svn cleanup to delete the lock and re-execute it. . .
$ cd iotdb-dist-dev
$ (gpg2 --list-sigs YOUR_NAME@apache.org && gpg2 --export --armor YOUR_NAME@apache.org) >> KEYS
$ svn ci -m "add gpg key for YOUR_NAME"
Next I will enter the username and password, just use the apache username and password.
d.2 Add the public key to KEYS in the release branch to release the official version
Note that the following command will create an iotdb-dist-release folder, preferably cd .. to the superior directory of iotdb-dist-dev
$ svn co https://dist.apache.org/repos/dist/release/incubator/iotdb iotdb-dist-release
$ cd iotdb-dist-release
$ (gpg2 --list-sigs YOUR_NAME@apache.org && gpg2 --export --armor YOUR_NAME@apache.org) >> KEYS
$ svn ci -m "add gpg key for YOUR_NAME"
e. Modify your maven settings
Suppose your maven local warehouse address is ~ / .m2.
If you already have a ~ / .m2 / settings.xml file, add the following <server> item, otherwise create a ~ / .m2 / settings.xml file:
Code Block | ||||
---|---|---|---|---|
| ||||
<?xml version="1.0" encoding="UTF-8"?>
<settings xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.1.0 http://maven.apache.org/xsd/settings-1.1.0.xsd" xmlns="http://maven.apache.org/SETTINGS/1.1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<servers>
<!-- Apache Repo Settings -->
<server>
<id>apache.snapshots.https</id>
<username>{user-id}</username>
<password>{user-pass}</password>
</server>
<server>
<id>apache.releases.https</id>
<username>{user-id}</username>
<password>{user-pass}</password>
</server>
</servers>
</settings>
<profiles>
<profile>
<id>apache-release</id>
<properties>
<gpg.keyname>你的KEYID</gpg.keyname><!-- Your GPG Keyname here -->
<!-- Use an agent: Prevents being asked for the password during the build -->
<gpg.useagent>true</gpg.useagent>
<gpg.passphrase>你的私钥的密码</gpg.passphrase>
</properties>
</profile>
</profiles> |
f. Upload GPG public key to Github account
!!important!! Many tutorials do not mention this step, and if you do not do this step, when you do some steps, maven will tell you that you do not have permission. .
method:
enter https://github.com/settings/keys ,Add GPG KEYS.
If you find that after the key is added "unverified" , remember to bind the email used in the GPG key to your github account (https://github.com/settings/emails )。
2. Ready to release version
(Note: Different projects may adopt different branch management methods, which are for reference only)
There are two situations here:
- I just sent a small version of the changes, for example, there is already a 0.8.0 version, I need to release 0.8.1. The characteristic is: There is already a branch of rel / 0.8 in the code warehouse.
- I want to publish a large version, the characteristic is: there is rel / 0.8 in the code warehouse, but there is no rel / 0.9
For the first case, you only need to switch the local branch to this remote branch:
$git checkout -b rel/0.8 origin/rel/0.8
For the second case, you need to create a new branch rel / 0.9 and push it to github:
$git checkout -b rel/0.9
$git push -u origin rel/0.9
2.1 Code ready for release
Let's take 0.8.1 as an example, assuming that the current local working branch has been switched to rel / 0.8.
This is the current branch graph. The last updated position after the creation of rel / 0.8 is shown in yellow, and the master is still moving forward.
First of all, we need to determine what content needs to enter the new release, for example, we want to put 1, 2 into 0.8.1, then add the two PR submissions to the rel one by one by the method of `git cherry-pick` /0.8 branch (you may have to resolve a lot of conflicts ...).
Then, modify the RELEASE_NOTES.md file and write about any updates in this release.
- For bug fixes, if there is an issue number, be sure to write the number.
- For the new feature, a short sentence / keyword description, you can also consider adding a usage introduction link.
And so far, the preparation work is done.
Note that so far, the version number in pom is: 0.8.1-SNAPSHOT
Then submit all local modifications to the remote.
When you frequently switch branches, some junk files will be left locally. For example, a folder session is added to the master branch, but not in 0.8. When you switch from master to rel / 0.8, the session folder cannot be cleared by mvn clean.
It is recommended to delete all these folders first (according to the PLC4X documentation, if you do not delete these files, these files will be packaged into source.zip ...)
!then!Be sure to check that all versions are correct。For example, if you are upgrading from 0.8.0 to 0.8.1, then:
- Search for /0.8.0/ (including the left and right "/"), so that you can replace the links in all documents with /0.8.1/
- Search for 0.8.0, check whether the function descriptions related to version 0.8.0 appearing in all documents are correct, and amend to 0.8.1
- Search for 0.8.0, pay attention to whether the console output in the Java code needs to be modified (for example, the CLI will print the version number)
- Note that the magic number of TsFile does not have to be modified. This needs to be discussed.
- Do not remove the -SNAPSHOT version in all pom. After removing it, the following command will report an error.
Then start the official release.
3.release version
3.1 Automatically tag on github and generate various signature files
First delete .mvn / wrapper / *. Jar in the project source code
Delete possible data directory
Ensure that no iotdb server is running locally, otherwise the test will occupy the port
Confirm again that it is now in the rel / 0.8 branch, and not in the master branch
merge the remote rel / 0.8 branch to ensure that the current local branch is up to date
Confirm that the local and remote release / 0.8.1 tags are deleted:
Delete local tag:$git tag -d release/0.8.1
Delete remote tag:git push origin :refs/tags/release/0.8.1
execute:
$ mvn release:prepare -DautoVersionSubmodules=true
When executed, it will let you enter three contents:
a. The version number you want to release. The default value is the version number in the pom. Remove "-SNAPSHOT"
b. What is the name of the tag I want to play on github, the default value is rel / 0.8.1, note that the naming style we currently use is: release / 0.8.1
c. What is the next version number, the default value is generally correct.
(Note: It is known that CRLF is used to mark the end of a line in Windows, and only LF is used to mark the end of a line in Linux / UNIX systems. After git sets core.autocrlf = true, git will convert the newline character of the text file to CRLF (only convert the file of pure LF) when checking out, and the content of the temporary area (that is, the changes we made to the work area) when submitting ) Convert to LF and put into the repository. In other words, if you are in a windows environment and core.autocrlf = true, the newline character downloaded from github to the local incubator-iotdb will become CRLF, so directly execute mvn release: prepare -DautoVersionSubmodules = true CRLF is still used in the zip package. One of such effects is that after copying the zip to the linux environment and decompressing it, you will find that the shell file cannot be executed directly. There seems to be a way to find online is to temporarily set core.autocrlf = input when downloading the source code, but I have not tried it, there may be other side effects. I went directly to the ubuntu virtual machine to do this again, remember to import the gpg key.)
This process will automatically delete the "-SNAPSHOT" version in the pom, and then create a tag in the cloud.
Finally, success will be prompted, and all but the first parent's pom will be skippted.
If successful, according to the PLC4X documentation, you should also go to the Apache warehouse to see if there is the latest record. The address is https://gitbox.apache.org/repos/asf?p=incubator-iotdb.git;a=shortlog;h=refs/heads/rel/0.8 Note the branch name.
You should see the git operation done automatically by mvn release: prepare just now. The commit log is:[maven-release-plugin] prepare release release/0.8.1 and [maven-release-plugin] prepare for next development iteration
In addition, if successful, the following files are generated in the local directory:
Under the target directory:
apache-iotdb-0.8.1-incubating-source-release.zip
apache-iotdb-0.8.1-incubating-source-release.zip.asc
apache-iotdb-0.8.1-incubating-source-release.zip.sha512
Under the distribution / target / directory:
apache-iotdb-0.8.1-incubating-bin.zip
apache-iotdb-0.8.1-incubating-bin.zip.asc
apache-iotdb-0.8.1-incubating-bin.zip.sha512
验证!有问题赶紧改,这里还有悔过的机会,不然RC++
gpg2 --verify target/apache-iotdb-0.9.0-incubating-source-release.zip.asc target/apache-iotdb-0.9.0-incubating-source-release.zip
gpg2 --verify distribution/target/apache-iotdb-0.9.0-incubating-bin.zip.asc distribution/target/apache-iotdb-0.9.0-incubating-bin.zip
shasum -a512 target/apache-iotdb-0.9.0-incubating-source-release.zip
shasum -a512 distribution/target/apache-iotdb-0.9.0-incubating-bin.zip
Then compare it with the .sha512 file to confirm the consistency.
Check the size of the source package and the binary package, the source package is a few M, the binary package is more than a dozen M is reasonable, otherwise check whether it has entered other things
In the source package ./mvnw clean install
In the binary package ./sbin/start-server.sh ./sbin/start-client.sh, check the version number and run some test statements:
SET STORAGE GROUP TO root.ChangSha;
CREATE TIMESERIES root.ChangSha.A.aa WITH DATATYPE=INT64, ENCODING=RLE;
CREATE TIMESERIES root.ChangSha WITH DATATYPE=INT64, ENCODING=RLE;
CREATE TIMESERIES root.ChangSha.A.ac WITH DATATYPE=INT64, ENCODING=RLE;
CREATE TIMESERIES root.ChangSha.B.aa WITH DATATYPE=INT64, ENCODING=RLE;
CREATE TIMESERIES root.ChangSha.B.ab WITH DATATYPE=INT64, ENCODING=RLE;
CREATE TIMESERIES root.ChangSha.B.ad WITH DATATYPE=INT64, ENCODING=RLE;
insert into root.ChangSha.A(timestamp,aa,ab,ac) values(1,1,1,1);
insert into root.ChangSha.A(timestamp,aa,ab,ac) values(3,1,1,1);
insert into root.ChangSha.B(timestamp,aa,ab,ad) values(1,1,2,2);
insert into root.ChangSha.B(timestamp,aa,ab,ad) values(2,1,2,2);
select * from root.ChangSha.* where time=1 and aa=1
If everything is successful, congratulations!
Possible reasons for unsuccessful:
(1)No permission for github repository.
(2)The local library is older than the remote library, you need to re-merge the remote branch
Regardless of the success or failure of all local pom files, there will be a file with the same name ending with releaseBackup.
If a failure occurs, first execute:
$ mvn release:rollback
If the execution also fails, execute it again. . Generally successful.
However, this rollback does not delete the tag, and it needs to be deleted manually.
Delete local tag:$git tag -d release/0.8.1
Delete remote tag:git push origin :refs/tags/release/0.8.1
(
In my case, I did not use the rollback command, but directly overwrite it again:
git fetch origin
git reset --hard origin/rel/0.9
git clean -fx -d // To remove ignored and non-ignored directories ⭐
git status // Check to confirm
git log // Check to confirm
)
maven official reference link:https://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html
3.2 Automatically download the source code from github, recompile and upload to Apache Nexus warehouse
execute:
$ mvn release:perform
It starts to publish and upload to the apache server.
...
...
long wait
...
...
I spent 46 minutes using the education network. .
(Note: It is recommended to perform this step in the morning, the network speed is much faster than at night)
maven official reference link:https://maven.apache.org/maven-release/maven-release-plugin/examples/perform-release.html
3.3 Perform signature verification
First open the website https://repository.apache.org (Turn it around and load it, then close and reopen several times)
Then click Login in the upper right corner! Log in with the apache account.
After the login is successful, Repositories in your left column will appear Staging Repositories, click on him, you can see the list below, find the line with the project name "orgapacheiotdb-number", select it and click the close button above
Then start waiting to complete the close, during which you can click refresh to update the page. You can also select iotdb and click the activity below to view the specific close progress and problems.
When there is no problem, start the next step.
If close fails, you can close it again. I encountered the problem of not finding my public key, but in fact it can be found on the Internet, and just close it again.
Note: After the close is successful, click the activity column and you will see the following successful operation information:
- open
- close
- Evaluating rules: Apache Rules
- Evaluating rule: Signature Validation
- Passed: Signature Validation
- Evaluating rule: Archives must not contain insecure paths
- Passed: Archives must not contain insecure paths
- Evaluating rule: Checksum Validation
- Passed: Checksum Validation
- All rules passed: Apache Rules
- Repository closed
3.3 Upload the compiled file to the dist website
Now you can upload all the content you need to dist.
For each release, you can release the RC1 version first, and then release the RC2 version if there is a problem, and so on. Before the vote is passed, it is released to dev, and after it is passed, it is moved to release.
3.3.1 Publish to dev
The address is https://dist.apache.org/repos/dist/dev/incubator/iotdb
This is actually an SVN repository. We have downloaded this SVN repository to the local site during the 1.d1 operation step. The local folder name is iotdb-dist-dev.
Let's temporarily use iotdb-dist-dev as the root directory, you will see the current directory as shown below (there should be no 0.8.1 folder)
Then create the 0.8.1 folder as shown in the figure above, and then create the 0.8.1 / rc1 folder.
Then copy README.md and RELEASE_NOTES.md from target / checkout / in the root directory of the iotdb source code.
Then copy it from iotdb source code / target / checkout / target / apache-iotdb-0.8.1-incubating-source-release.zip * (three files: zip, zip.asc, zip.sha512);
Copy it from Iotdb source code / target / checkout / distribution / target / apache-iotdb-0.8.1-incubating-bin.zip * (three files: zip, zip.asc, zip.sha512)
Then submit with the svn command:
$ svn add 0.8.1
If this directory is added, you need to add svn add 0.9.0 / rc2
$ svn commit -m "perparing RC1 of 0.8.1 of IoTDB release"
3.4 Mark the release on github as pre-release
Go to https://github.com/apache/incubator-iotdb/releases, find the release just hit, click edit tag, select This is a pre-release, and then Save draft
(This is because "the release is not stable, you must inform the user that the version is not yet suitable for production", so choose This is a pre-release (this is a pre-release version), refer to the link:https://help.github.com/cn/github/administering-a-repository/creating-releases)
3.5 write an email
Reference example: (be sure to check carefully for updates when writing by yourself)
mail title:[VOTE] Apache IoTDB 0.8.1 (incubating) RC2 release
Mail template:
Hi all,
(This sentence is optional) Apache IoTDB (incubating) 0.8.1 is a bug-fix version from 0.8.0. You can get its mainly changes from [5].
Apache IoTDB (Incubating) 0.8.1 has been staged under [2] and it’s time to vote
on accepting it for release. All Maven artifacts are available under [1].
If approved we will seek final release approval from the IPMC.
Voting will be open for 72hr.
A minimum of 3 binding +1 votes and more binding +1 than binding -1
are required to pass.
Release tag: release/0.8.1
Hash for the release tag: 37b213b6ab6fc8ca13ab60f21dff099042a0e295
Per [3] "Before voting +1 [P]PMC members are required to download
the signed source code package, compile it as provided, and test
the resulting executable on their own platform, along with also
verifying that the package meets the requirements of the ASF policy
on releases."
You can achieve the above by following [4].
[ ] +1 accept (indicate what you validated - e.g. performed the non-RM items in [4])
[ ] -1 reject (explanation required)
(This is also optional)Difference with RC1:
[1] https://repository.apache.org/content/repositories/orgapacheiotdb-1005
[2] https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.8.1/rc2
[3] https://www.apache.org/dev/release.html#approving-a-release
[4] https://cwiki.apache.org/confluence/display/IOTDB/Validating+a+staged+Release
[5] https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.8.1/rc2/RELEASE_NOTES.md
The red words above need to be changed.
The hash value of the tag can be obtained by the following command:
$ git show release/0.8.1 --name-only
4 What if the vote fails
When the vote fails, the battlefield needs to be cleared first, and then reposted.
First, close the release on the Nexus by logging in to repository.apache.org, then selecting the row just now, and clicking the Drop button.
Then manually delete the release and tag on github, as well as the local tag.
Delete remote tag:git push origin :refs/tags/release/0.8.1
Delete local tag:git tag -d release/0.8.1
Then use the maven plugin to manage the version:
$ mvn release:prepare -DautoVersionSubmodules=true
Of course, you can also use git revert to achieve this step.
Then began to modify the problems found in various polls. And submit to rel / 0.8.
Then jump to step 3 and start over.
And if the vote fails, write a RESULT email to inform the situation and the next step, for example, refer to the example of the previous release manager:
5. What to do after the vote is passed
After 72 hours of voting, a summary email should be made:
Reference example: (be sure to check carefully for updates when writing by yourself)
Panel |
---|
theme:[RESULT] [VOTE] Apache IoTDB (Incubating) {current-full-version} RC1 Hi, The vote closes now as 72hr have passed. The vote PASSES with The vote thread: https://lists.apache.org/thread.html/ee976b92c2a425a3172b840980a59eb2c4dd4361be7c198489010b49%40%3Cdev.iotdb.apache.org%3E I will now bring the vote to general@incubator.apache.org to get approval by the IPMC. Thank you for your support. / (Free thanks) Regards, |
This vote thread can be searched on this page:https://lists.apache.org/list.html?dev@iotdb.apache.org
Log in with an apache account, find the voting thread, and then the permalink on the right is a permanent link. Just click and copy the URL.
Subscribe to the general mailing list
Send an email to general-subscribe@incubator.apache.org and then confirm
In the incubator stage, you need to send an email to the general mailing list general@incubator.apache.org and hand it to the IPMC to vote.
Reference example: (be sure to check carefully for updates when writing by yourself)
Panel |
---|
Theme:[VOTE] Release Apache IoTDB 0.9.0 Hello all, The vote will be passed if there is no -1 vote ( as there are 3 IPMC +1 votes already), but we still hope all other IPMCs vote for it. Please vote accordingly: |
6. What to do after the general list vote
First send a summary email to the general mailing list
Reference example: (be sure to check carefully for updates when writing by yourself)
Panel |
---|
Theme:[RESULT][VOTE] Release Apache IoTDB 0.9.0 Hi all, xxx non-binding vote:
Your name |
Move the released files from the dev repository to the release svn project.
The svn address of the release is:https://dist.apache.org/repos/dist/release/incubator/iotdb
If it is the first time, you can clone this repository, then add files, and then submit.
$svn co https://dist.apache.org/repos/dist/release/incubator/iotdb
$cd iotdb
$Copy the file and put it under version-incubating. For example, the following 0.8.1-incubating is what I just put in the past.
MacBook-Pro-3:iotdb-rel hxd$ tree .
.
├── 0.8.0-incubating
│ ├── README.md
│ ├── RELEASE_NOTES.md
│ ├── apache-iotdb-0.8.0-incubating-bin.zip
│ ├── apache-iotdb-0.8.0-incubating-bin.zip.asc
│ ├── apache-iotdb-0.8.0-incubating-bin.zip.sha512
│ ├── apache-iotdb-0.8.0-incubating-source-release.zip
│ ├── apache-iotdb-0.8.0-incubating-source-release.zip.asc
│ └── apache-iotdb-0.8.0-incubating-source-release.zip.sha512
├── 0.8.1-incubating
│ ├── README.md
│ ├── RELEASE_NOTES.md
│ ├── apache-iotdb-0.8.1-incubating-bin.zip
│ ├── apache-iotdb-0.8.1-incubating-bin.zip.asc
│ ├── apache-iotdb-0.8.1-incubating-bin.zip.sha512
│ ├── apache-iotdb-0.8.1-incubating-source-release.zip
│ ├── apache-iotdb-0.8.1-incubating-source-release.zip.asc
│ └── apache-iotdb-0.8.1-incubating-source-release.zip.sha512
└── KEYS
Then submit:
$svn add 0.8.1-incubating
$svn commit -m "upload 0.8.1 release files"
If your keys are also modified, you may need to update the keys file.
Note: All apache mirrors will start synchronizing these files, which will usually be synchronized within 24 hours. After that, you can send a statement email.
7. Delete the old version of the release file
Apache seems to require that when the new versions are synchronized, delete the files of the old version (for example, 0.8.0-incubating in this example), but I checked several projects, this is not absolutely required. . It is recommended to keep some versions.
The delete method is to delete the folder with the svn delete command.
E.g:$svn delete https://dist.apache.org/repos/dist/release/incubator/iotdb/0.8.0-incubating/ -m"deleted version 0.8.0"
It can also be deleted as follows:
svn delete The file or folder to be deleted
svn commit -m "Write commit log"
8. Officially release Maven files
Go to https://repository.apache.org/#welcome, log in to your account, then go to Staging Repositories to select the version you closed before and select release. Finished.
9. github publish release
Go to https://github.com/apache/incubator-iotdb/releases and change the previous this is a pre-release & save draft to publish release.
10. Update the code of the release branch to the latest
In our project, the release branch always points to the latest release version.
git checkout release
git merge release/0.8.1
If there is a conflict, then to receive the modification on the tag, you can use the following command:
git merge -X theirs release/0.8.1
11. Update JIRA
Set the released version to "released" and set the "release-date"
Add the next version to the versions.
I do n’t have permission so I have n’t tested it yet
12. Update the download link on the official website
Website Directory:
https://github.com/apache/incubator-iotdb-website
Just change the master branch directly, remember to pull the latest master
Document branches are uniformly used rel / 0.9, no tag, one document for each major version
For how to modify and add new versions on the official website, you can refer How to update IoTDB website for a new release
In fact, it is mainly to add one item, and the version number should be changed.
detail:
The official website download link currently requires the mirror terminal,
Binary download link binary-distribution:https://www.apache.org/dyn/closer.cgi/incubator/iotdb/0.8.0-incubating/apache-iotdb-0.8.0-incubating-bin.zip
SHA file and ASC file can use the address on svn:
Source download version source-release:https://www.apache.org/dyn/closer.cgi/incubator/iotdb/0.8.0-incubating/apache-iotdb-0.8.0-incubating-source-release.zip
SHA file and ASC file can use the address on svn:
The RELEASE_NOTE file can also be used on SVN, but when we open it on the web page on our project svn, we lose the line break. . So you can use github's raw file:
https://raw.githubusercontent.com/apache/incubator-iotdb/release/0.8.1/RELEASE_NOTES.md
Change the above version to your final version.
13. Tell the world!
After you confirm that most of the mirrors are synchronized, you can tell the world to release a new version of the information:
Mailbox for sending emails: it must be the mailbox of apache.org, otherwise it will be rejected.
Send mail to:announce@apache.org
Cc mail to:dev@iotdb.apache.org
Message subject:[ANNOUNCE] Apache IoTDB (incubating) 0.8.1 released
Example of message content:
Panel |
---|
The Apache IoTDB team is pleased to announce the release of Apache IoTDB (incubating) 0.8.1. Apache IoTDB (incubating) (Database for Internet of Things) is an integrated data management engine designed for timeseries data. It provides users with services for data collection, storage and analysis. The current release is a bug-fix version of 0.8.0, which will makes IoTDB more stable:
Visit the Apache IoTDB website [1] for general information or Regards, [1] http://iotdb.apache.org ===== Disclaimer Apache IoTDB (incubating) is an effort undergoing incubation at The |
More reference examples:https://lists.apache.org/list.html?dev@iotdb.apache.org:gte=1d:announce
Publish Python package to Pypi
First, you must have an account, register here:https://pypi.org/account/register/
Secondly, it is better to register an account of the test warehouse, here https://test.pypi.org/account/register/
Note: Make sure there are no problems in the test warehouse before the official release. Because after the official release PyPI does not allow for a filename to be reused, even once a project has been deleted and recreated.
That is, there are problems after the official release. Even if the package is deleted, the names already used (such as apache-iotdb 0.9.1) can no longer be used for re-uploading.
You need to install python3 and pip3 on your computer; after installation, you also need to install setuptools, wheel and twine
python3 -m pip install --user --upgrade setuptools wheel
python3 -m pip install --user --upgrade twine
When I execute the above command, I get an error: creating build/temp.linux-x86_64-3.6/build/temp.linux-x86_64-3.6
x86_64-linux-gnu-gcc -pthread -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/usr/include/python3.6m -c build/temp.linux-x86_64-3.6/_openssl.c -o build/temp.linux-x86_64-3.6/build/temp.linux-x86_64-3.6/_openssl.o -Wconversion -Wno-error=sign-conversion
build/temp.linux-x86_64-3.6/_openssl.c:22:24: fatal error: pyconfig.h: No such file or directory
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
解决办法:sudo apt install python3.6-dev (My python is version 3.6)
Then, after the entire project is compiled (actually, after executing the service-rpc generate-sources), enter the service-rpc / target / generate-sources-python folder.
(note:The version numbers, links, etc. in incubator-iotdb/service-rpc/src/pypi/setup.py and incubator-iotdb/service-rpc/src/pypi/README.md should be in step 2 “Preparing for release” The update is complete.)
Console operation:python3 setup.py sdist bdist_wheel
Then you can publish:
If it is the first release, you can experiment in the test warehouse:
python3 -m twine upload --repository-url https://test.pypi.org/legacy/ dist/*
Note: When uploading the test version, the name in setup.py used by python3 setup.py sdist bdist_wheel needs to be modified, and you can add your own username in the suffix (like this: name = "example-pkg-YOUR-USERNAME-HERE" ), Otherwise no error will be reported: The credential associated with user 'xxx' isn't allowed to upload to project 'apache-iotdb'. Before officially uploading, remember to change the name in setup.py back to regenerate.
Sample output after completion:
Panel |
---|
MacMini-FIT:generated-sources-python hxd$ python3 -m twine upload --repository-url https://test.pypi.org/legacy/ dist/* View at: |
Webpage effect:https://test.pypi.org/project/apache-iotdb/
Then you can download and try it locally:
Panel |
---|
(The official tutorial recommends using virtualevn, but my pip install package does not take effect in virtualevn): python3 -m pip install --index-url https://test.pypi.org/simple/ apache-iotdb==0.9.0-rc5 (Assuming the version is 0.9.0-rc5) python3 -m pip install --index-url https://test.pypi.org/simple/ --no-deps apache-iotdb==0.9.0-rc5 (Assuming the version is 0.9.0-rc5) But it's useless. . Because it cannot be run without thrift. . So the exact process is: python3 -m pip install thrift==0.13.0 python3 -m pip install --index-url https://test.pypi.org/simple/ --no-deps apache-iotdb==0.9.0-rc5 Then run client-example.py under client-py to see if it is correct. If you are not in a virtualevn environment, remember to delete this temporary package after use: python3 -m pip uninstall apache-iotdb |
Everything is OK, you can officially release: (Note: If you have modified setup.py for testing before, remember to change the name in setup.py here to regenerate the dist folder)
python3 -m twine upload dist/*
Note: If you do not have upload permission, find the project administrator.
This part refers to
https://packaging.python.org/tutorials/packaging-projects/
Publish Docker image package to DockerHub
First, you need to have a username under the dockerhub website.
Secondly, you need to apply to JIRA's INFRA project to add the permissions of the apache / iotdb project in dockerhub to your username.
The above preparations are completed.
Then write a Dockerfile script, the example of 0.9.1 is as follows (the script needs to be modified according to the actual deployment method of each version):
No Format |
---|
FROM openjdk:11-jre-slim
RUN apt update \
# procps is for `free` command
&& apt install wget unzip lsof procps -y \
#&& wget https://www-us.apache.org/dist/incubator/iotdb/0.9.1-incubating/apache-iotdb-0.9.1-incubating-bin.zip \
&& wget http://mirrors.tuna.tsinghua.edu.cn/apache/incubator/iotdb/0.9.1-incubating/apache-iotdb-0.9.1-incubating-bin.zip \
&& unzip apache-iotdb-0.9.1-incubating-bin.zip \
&& rm apache-iotdb-0.9.1-incubating-bin.zip \
&& mv apache-iotdb-0.9.1-incubating /iotdb \
&& apt remove wget unzip -y \
&& apt autoremove -y \
&& apt purge --auto-remove -y \
&& apt clean -y
EXPOSE 6667
EXPOSE 31999
EXPOSE 5555
EXPOSE 8181
VOLUME /iotdb/data
VOLUME /iotdb/logs
ENV PATH="/iotdb/sbin/:/iotdb/tools/:${PATH}"
ENTRYPOINT ["/iotdb/sbin/start-server.sh"] |
Then construct the image locally (note that there are no other files in the Dockerfile folder when running):
docker build -t apache/iotdb:0.9.1 .
Then try to run locally:
docker run -d -p 6667:6667 -p 31999:31999 -p 8181:8181 apache/iotdb:0.9.1
If you need to kill the image, use docker ps to view the container id, and then use docker kill container id.
Carry out the test, start iotdb-client to connect and add, delete, modify and check operations:
docker exec -it a4434aff6123 /bin/bash
If there is no problem, you can upload the mirror:
First you need to log in to docker:
docker login --username=yourhubusername
Use docker images to confirm the container and the tag of the container again:
Taking the above picture as an example, the reason why apache / iotdb 0.9.0 and 0.9.1 have the same Image ID is that when I built 0.9.1, I mistakenly specified the version number as 0.9.0.
Therefore, after building the image, you must use the client to connect to iotdb for testing.
If the name is not of the type apache / iotdb when building the image, or the version number is incorrect, there is a chance to modify:
docker tag 6a6365cd99d0 apache/iotdb:0.9.1
Upload it:
docker push apache/iotdb:0.9.1
If it is the latest version (for example, there is no 0.10, then 0.9.x is the latest version. But assuming that 0.10.0 has been released, then uploading 0.9.5 is not the latest version), and update the latest label:
docker tag apache/iotdb:0.9.1 apache/iotdb:latest
docker push apache/iotdb:latest
Finished。
That is all.