How to release

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：

1. https://plc4x.apache.org/developers/release.html
2. 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：

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.

$ 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:

$ 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

http://keys.gnupg.net

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:

-----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:

<?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>Your 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>The password of your private key</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

verification! If you have any problems, quickly correct them, and there is still a chance to regret it, otherwise 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

[6] https://dist.apache.org/repos/dist/dev/incubator/iotdb/KEYS

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:

https://lists.apache.org/thread.html/89b0af63c0af7455641f738e2500a8a92a2cb4f9efca5456371bf06f%40%3Cdev.iotdb.apache.org%3E

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)

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)

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)

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

1. Set the released version to "released" and set the "release-date"

2. 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 如何更新 IoTDB 官网

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:

SHA：https://www.apache.org/dist/incubator/iotdb/0.8.0-incubating/apache-iotdb-0.8.0-incubating-bin.zip.sha512

ASC：https://www.apache.org/dist/incubator/iotdb/0.8.0-incubating/apache-iotdb-0.8.0-incubating-bin.zip.asc

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:

SHA：https://www.apache.org/dist/incubator/iotdb/0.8.0-incubating/apache-iotdb-0.8.0-incubating-source-release.zip.sha512

ASC：https://www.apache.org/dist/incubator/iotdb/0.8.0-incubating/apache-iotdb-0.8.0-incubating-source-release.zip.asc

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:

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
Solution：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:

Webpage effect：https://test.pypi.org/project/apache-iotdb/

Then you can download and try it locally:

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)

Note that if the above command fails, it means that there is no thrift package under this test pypi. At this time, you can use the --no-deps parameter to skip the thrift installation:

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):

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.