Versions Compared

Old Version 40

changes.mady.by.user Justin Leet

Saved on

compared with

New Version Current

changes.mady.by.user Jon Zeolla

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Add reminder to point to new plugin versions after release

...

Metron build naming convention is as follows: 0.[FR].[MR].  We keep the 0. notation to signify that the project is still under active development and we will hold a community vote to go to 1.x at a future time.  The first release in a Feature Release line is 0.[FR].0.  There may or may not ever be a release 0.[FR].1, depending whether the community decides to create follow-on Maintenance Release(s) or just go straight to the next Feature Release (which would be named 0.[FR+1].0).

 


Creating a Feature Release

...

  • Do an SVN clone of the repo at https://dist.apache.org/repos/dist/dev/metron. We will refer to this as the dev repo.  It will hold the release candidate artifacts
  • Do an SVN clone of the repo at https://dist.apache.org/repos/dist/release/metron. We will refer to this as the release repo.  It will hold the release artifacts.
  • Do a Git clone of the repo at https://git-wip-us.apache.org/repos/asf/metron.git.  This holds the source code for the release candidate.
  • Create appropriate tags (following the naming convention `git tag apache-metron-_0.[FR].[MR]-rc[N]`).
  • Create the release tarball (following the naming convention apache-metron-_0.[FR].[MR]-rc[N].tar.gz). 
  • Create the appropriate release artifacts. The script will create these, and manual instructions are provided here:
    • Release (candidate) Tarball
    • Per Apache guidance, we use SHA512 hash digests in the signing process, see here for how to set your gpg defaults, and upgrade your signing keys if you have old ones.  Likewise, do not use 4-byte fingerprints, like "DEAD BEEF" or "0xDEADBEEF", to refer to your signing key, as these have been demonstrated vulnerable.  Instead use 8-byte fingerprints, like "BADD CAFE DEAD BEEF" or "0xBADDCAFEDEADBEEF".
    • SHA512 hash of the release tarball; here we will also provide SHA256 hashes for backward compatibility:
      • gpg --print-md SHA512 apache-metron-_0.[FR].0[MR]-rc1.tar.gz > apache-metron-_0.[FR].0[MR]-rc1.tar.gz.sha512
      • gpg --print-md SHA256 apache-metron-_0.[FR].0[MR]-rc1.tar.gz > apache-metron-_0.[FR].0[MR]-rc1.tar.gz.sha256
    • GPG signature of release tarball by the release manager
      •  Assuming your 8-byte public code signing key fingerprint is 0xBADDCAFEDEADBEEF, so your signing command would be: gpg -u 0xBADDCAFEDEADBEEF --armor --output apache-metron-_0.[FR].0[MR]-rc1.tar.gz.asc --detach-sig apache-metron-_0.[FR].0[MR]-rc1.tar.gz
      • Note: You only need the -u arg if you have more than one public/private key pair generated.  If you have forgotten it, you can find it from the output of gpg --fingerprint.  It’s the last 8 bytes (16 hex characters) from the key fingerprint.
      • If you do not know, or cannot recover, your code signing key and password as release manager, you must start over with a new code signing key. Follow the instructions at https://www.apache.org/dev/release-signing.html#generate .  You should then link your new code signing key into Apache's web of trust.
    • The LICENSE and NOTICE files from the release tarball
    • The KEYS file from the release tarball
    • A CHANGES file denoting the changes
  • Create the directory in the dev repo for the artifacts (following the convention `0.[FR].[MR]-RC[N]`).  A live run will also commit them (`svn commit -m "Adding artifacts for Metron 0.[FR].[MR]-RC[N]"`). A practice run will simply print the commands.

Historical Note:  Releases for Metron versions 0.6.0 and earlier used a - to delineate the prefix (apache-metron) from the version/release information (such as 0.6.0-release or 0.6.0-rc1).

Step 6 - Push the Step 6 - Push the Git Tag

When you're confident this release candidate is worthy to be tested by the community, push the tag to the public git repo.  Chdir back to the local repo from which you created the release candidate tarball, and verify that the tag is present:

...

git push origin tag apache-metron-_0.[FR].[MR]-rc[N]

 Browse the public repo and confirm the tag has been pushed successfully.

...

After the vote passes, re-tag the RC as the release.  In your working repo for the release (cloned from https://git-wip-us.apache.org/repos/asf/metron.git), do:

git tag  apache-metron-_0.[FR].[MR]-release  apache-metron-_0.[FR].[MR]-rc[N]

git push origin tag apache-metron-_0.[FR].[MR]-release

apache/metron-bro-plugin-kafka

...

git tag  apache-metron-bro-plugin-kafka-_0.[FR].[MR]-release  apache-metron-bro-plugin-kafka-_0.[FR].[MR]-rc1

git tag 0.[FR] apache-metron-bro-plugin-kafka-_0.[FR].[MR]-release

git push origin tag apache-metron-bro-plugin-kafka_0.[FR].[MR]-release

git push origin tag 0.[FR]

The 0.[FR] tag is created to allow the release to be handled appropriately by bro-pkgpkg.  Note that we expect to be able to change this to 0.[FR].[MR] as of the release of bro 2.7 via https://github.com/bro/bro/commit/615ff782824fb6d1be889e3544eb034c0b6891a4, but it would need to be coordinated with a chance in apache/metron-bro-plugin-kafka itself (https://github.com/apache/metron-bro-plugin-kafka/pull/8).

Step 9 - Stage the finished release

...

Collateral from the release candidate in the dev repo should be moved to the release repo directory and renamed to remove the rc (e.g. mv apache-metron-_0.[FR].0[MR]-rc1.tar.gz apache-metron-_0.[FR].0[MR].tar.gz)

Regenerate the sha* files (but NOT the asc signature file), and compare against the original to confirm they have exactly the same hash fingerprints.  Alternatively one may edit the sha* files to remove the "-rc1" internal references, but there is greater potential for human error with a manual edit.

Add the directory and commit via the subversion client:

svn add 0.[FR].0[MR]
svn commit -m "Adding artifacts for Metron 0.[FR].0[MR]"

Confirm that the new release is visible in dist, by pointing your browser at https://dist.apache.org/repos/dist/release/metron/ .  It should appear promptly, but may not be instantaneous.

...

cd <workdir>

git clone https://github.com/apache/metron.git

cd metron

git checkout -b METRON-1234  apache-metron-_0.[FR].[MR]-release

Now rebuild the doc and web sites, and copy the built site-book to site/current-book

...

It is good practice to increment the build version in master immediately after a Feature Release, so that dev builds with new stuff from master cannot be mistaken for builds of the release version. So, immediately after a release, increment the MINOR version number (eg, with the 0.4.0 just released, set the new version number to 0.4.1) per Change the Build Version Number.

In addition, if a new version of apache/metron-bro-plugin-kafka has been released, the development environments in apache/metron should be updated to point to the latest plugin release.

Creating a Maintenance Release

...