Preliminaries

Apache Release Documentation

Permission requirements

The following permissions are required to perform release manager duties.

Apache dist server (https://dist.apache.org/repos/dist) subversion privileges (PMC Member)
Applying git release tags (Project committer)

Apache Release Documentation

Code Signing Key

Create a code signing gpg key for release signing; use <your Apache ID>@apache.org for your primary ID for the code signing key. See the Apache Release Signing documentation for further information.

Add your code signing key to your Apache ID here
Add it to the HAWQ KEYS MADlib KEYS files in the dev and release subversion repositories:
- dev: https://dist.apache.org/repos/dist/dev/incubator/madlib/KEYS
- release: https://dist.apache.org/repos/dist/release/incubator/madlib/KEYS

Ensure JIRA Issues are Appropriately Tagged for the Release

Ensure that all HAWQ MADlib JIRA issues that are addressed in this release are marked with the release version in the ‘FixVersion’ field of the issue.

...

Creating and Validating the Release Candidate

Prepare Tarballs

Send email to dev@madlib.incubator.apache.org for instructions on how to do this.

Prepare rpm and dmg binaries

Send email to dev@madlib.incubator.apache.org for instructions on how to do this.

Sign the Release Candidate

Check that md5, shasum, and gpg (or gpg2) are installed on your machine:

$ which md5
/sbin/md5

$ which shasum
/usr/bin/shasum

$ which gpg
/usr/local/bin/gpg

Install using Hombrew (on Mac OS) if needed e.g.:

Prepare MD5, SHA256 and ASC files from the source tarball and binaries:

md5 <your release tarball or binary> > <your release tarball or binary>.md5
shasum -a 512 <your release tarball or binary> > <your release tarball or binary>.sha512 
gpg --detach-sign -a <your release tarball or binary>

Example:

$ md5 apache-madlib-1.11-incubating-src.tar.gz > apache-madlib-1.11-incubating-src.tar.gz.md5
$ shasum -a 512 apache-madlib-1.11-incubating-src.tar.gz > apache-madlib-1.11-incubating-src.tar.gz.sha512
$ gpg --detach-sign -a apache-madlib-1.11-incubating-src.tar.gz

You need a passphrase to unlock the secret key for
user: "Rashmi Raghu (CODE SIGNING KEY) <rashmiraghu@apache.org>"
4096-bit RSA key, ID 28D2C789, created 2017-05-01

$ ls -la

...

Build is successful (Refer to the installation guide for build instructions). Also check the Jenkins build to make sure it does not show any errors: https://ci-builds.apache.org//job/Madlib/job/madlib-build/
LICENSE and NOTICE files are correct and dependency licenses are acceptable
- LICENSE and NOTICE files at the root of the artifact directory must only reflect the contents of the artifact in which they are contained.
- See:
  - LICENSE file requirements
  - LICENSE requirements for distribution artifacts with multiple licenses
  - NOTICE file requirements (Check Copyright year)
  - Apache Legal
  - Acceptable and Unacceptable Dependency Licenses
All source files have license headers where appropriate, RAT checks pass
- Additional check:
  - pom.xml
The provenance of all source files is clear (ASF or software grants)
Create the Release Candidate
Sign the Release Candidate
Verify the Release Candidate signatures
Commit artifacts to the dev Apache dist site for release candidates

Create the Release Candidate

Prepare Release Notes

See example release notes from previous releases on the wiki site and prepare similar notes.

https://cwiki.apache.org/confluence/display/MADLIB/MADlib+1.11

Update the wiki with these release notes for the new release
Update the release notes file in the source code: https://github.com/rashmi815/incubator-madlib/blob/master/RELEASE_NOTES (create PR and merge)

Prepare Tarballs

Created signed annotated git tag on release branch
git tag -u <GPG KEY ID> --sign <your release name>-rc# -m "Apache MADlib <your release name> RC#" <SHA of HEAD of branch>

Example:
$ git tag -u 57325522 --sign rc/1.12-rc1 -m "Apache MADlib 1.12 RC1" 46795de0254d2cb7755ee9336be5fef2a187e8c9
If the -u option doesn't work, then you can also try updating the global git config with your key (It might also be possible to update just the local git config instead of the global config but we haven't tried doing that)
```
git config --global user.signingkey <KEY>
git tag --sign rc/1.12-rc1 -m "Apache MADlib 1.12 RC1" 46795de0254d2cb7755ee9336be5fef2a187e8c9
```

Make a tarball and gzip:

git archive -o ../apache-madlib-<your release name>-src.tar --prefix=apache-madlib-<your release name>-src/ <your tag/branch name>
gzip ../apache-madlib-<your release name>-src.tar

Example:

$ git archive -o ../apache-madlib-1.12-src.tar --prefix=apache-madlib-1.12-src/ rc/1.12-rc1
$ gzip ../apache-madlib-1.12-src.tar

NOTE: Depending on release requirements, an alternate approach is to create a release branch to which the tag will be applied.

Branch your release:

git checkout -b <your release name> <commit sha1>

push to origin:

git push origin <your release name>

Sign the Release Candidate

Check that shasum, and gpg (or gpg2) are installed on your machine:

$ which gpg shasum
/usr/local/bin/gpg
/usr/bin/shasum

Install using Hombrew (on Mac OS) if needed e.g.:

$ brew install gnupg
==> Downloading ftp://ftp.gnupg.org/gcrypt/gnupg/gnupg-1.4.19.tar.bz2
######################################################################## 100.0%
==> ./configure --disable-silent-rules --prefix=/usr/local/Cellar/gnupg/1.4.19 --disable-asm
==> make
==> make check
==> make install

/usr/local/Cellar/gnupg/1.4.19: 53 files, 5.4M, built in 87 seconds
office-4-125:release_manager_stuff rraghu$ which gpg
/usr/local/bin/gpg

Prepare SHA256 and ASC files from the source tarball and binaries:

shasum -a 512 <your release tarball or binary> > <your release tarball or binary>.sha512
gpg --detach-sign -a <your release tarball or binary>

Example:

$ shasum -a 512 apache-madlib-1.11-src.tar.gz > apache-madlib-1.11-src.tar.gz.sha512
$ gpg --detach-sign -a apache-madlib-1.11-src.tar.gz

You need a passphrase to unlock the secret key for
user: "Rashmi Raghu (CODE SIGNING KEY) <rashmiraghu@apache.org>"
4096-bit RSA key, ID 28D2C789, created 2017-05-01

$ ls -gGnl

-rw-r--r-- 1 20 3156110 Mar 31 11:52 apache-madlib-1.18.0-src.tar.gz

-rw-r--r--

...

1 20 833 Mar 31 12:36 apache-madlib-1.

...

18.0-

...

src.tar.gz.

...

asc

-rw-r--r-- 1 20 162 Mar 31 12:36 apache-madlib-1.18.0-src.tar.gz.sha512

Validate the Release Candidate

As per the Apache documentation, verify that the release candidate artifacts satisfy the following:

PGP signatures and SHA256/MD4 checksum verification

Example (performed on a Macbook Pro: brew install gpg2 coreutilsMac OS):

$ brew install gpg2 coreutils
brew install gpg2 coreutils
Warning: gnupg2-2.0.30_3 already installed
Warning: coreutils-8.26 already installed
$ which gpg2 gsha256sum gmd5sum
gpg coreutils

$ which gpg gsha512sum
/usr/local/bin/gpg
/usr/local/bin/gpg2
/usr/local/bin/gsha256sum
/usr/local/bin/gmd5sum
$ gpg2 --import ../KEYS
gpg: directory `/Users/espino/.gnupg' created
gpg: new configuration file `/Users/espino/.gnupg/gpg.conf' created
gpg: WARNING: options in `/Users/espino/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/Users/espino/.gnupg/secring.gpg' created
gpg: keyring `/Users/espino/.gnupg/pubring.gpg' created
gpg: /Users/espino/.gnupg/trustdb.gpg: trustdb created
gpg: key D0D6D44A: public key "Caleb Welton <cwelton@apache.org>" imported
gpg: key 9AF9C0EE: public key "Ting (Goden) Yao (CODE SIGNING KEY) <godenyao@apache.org>" imported
gpg: key 8051460D: public key "Ting (Goden) Yao (CODE SIGNING KEY) <godenyao@apache.org>" imported
gpg: key 9475BD5D: public key "Roman V Shaposhnik (CODE SIGNING KEY) <rvs@apache.org>" imported
gpg: key 2858A0C9: public key "Lei Chang <lei_chang@apache.org>" imported
gpg: key 57325522: public key "Edward Bartolo Espino (CODE SIGNING KEY) <espino@apache.org>" imported
gpg: Total number processed: 6
gpg: imported: 6 (RSA: 5)
gpg: no ultimately trusted keys found
$ gpg2 --verify apache-hawq-src-2.1.0.0-incubating.tar.gz.asc
gpg: assuming signed data in 'apache-hawq-src-2.1.0.0-incubating.tar.gz'
gpg: Signature made Tue Jan 10 17:25:01 2017 CST using RSA key ID 57325522
gpg: Good signature from "Edward Bartolo Espino (CODE SIGNING KEY) <espino@apache.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: BBED A7B5 F336 D516 B34A DE0C FC06 62F2 5732 5522
$ gsha256sum --check apache-hawq-src-2.1.0.0-incubating.tar.gz.sha256
apache-hawq-src-2.1.0.0-incubating.tar.gz: OK
$ gmd5sum --check apache-hawq-src-2.1.0.0-incubating.tar.gz.md5
apache-hawq-src-2.1.0.0-incubating.tar.gz: OK

Build is successful (Refer to Build and Install for build instructions)
DISCLAIMER is correct, filenames include “incubating”
LICENSE and NOTICE files are correct and dependency licenses are acceptable
- LICENSE and NOTICE files at the root of the artifact directory must only reflect the contents of the artifact in which they are contained.
- See:
  - LICENSE file requirements
  - LICENSE requirements for distribution artifacts with multiple licenses
  - NOTICE file requirements (Check Copyright year)
  - Apache Legal
  - Acceptable and Unacceptable Dependency Licenses
All source files have license headers where appropriate, RAT checks pass
- Additional check:
  - pom.xml (For artifactId "hawq", verify version is consistent with the version specified in getversion file in the root directory).
The provenance of all source files is clear (ASF or software grants)

Commit artifacts to Apache dist site:

Retrieve the subversion dev incubator hawq repo
Example: svn checkout https://dist.apache.org/repos/dist/dev/incubator/hawq/ --username=<your apache user>
Create a local folder for the release (e.g. 2.0.0.0-incubating.RC1) in svn. We use apache's distribution repo: https://dist.apache.org/repos/dist/dev/incubator/hawq/
Move the files into the release folder on local disk.
svn add <release folder>
Commit artifacts:
Example: svn commit -m 'adding 2.0.0.0-incubating RC1 candidate release artifacts' --username=<your apache user id>

Vote on the Release

As per the Apache Incubator release guidelines, all releases for incubating projects must go through a two-step voting process. First, release voting must successfully pass within the Apache HAWQ community via the dev@hawq.incubator.apache.org mail list. Then, release voting must successfully pass within the Apache Incubator PMC via the general@incubator.apache.org mail list.

General information regarding the Apache voting process can be found here.

Apache HAWQ Community Vote

To vote on a candidate release, send an email to the dev list with subject: [VOTE]: Apache HAWQ <release version> Release and a body similar to the template below. Use a Text Editor without formatting when composing the email.

This is the vote for <release name> of Apache HAWQ (incubating). This is a Source only release.

The vote will run for at least 72 hours and will close on <vote closing date>.

Release Notes (Jira generated):
 <JIRA Release Notes URL>

Release verification steps can be found at:
 https://cwiki.apache.org/confluence/display/HAWQ/Release+Process%3A+Step+by+step+guide#ReleaseProcess:Stepbystepguide-ValidatetheReleaseCandidate

gsha512sum

$ gpg --verify apache-madlib-1.11-bin-Linux.rpm.asc
gpg: assuming signed data in `apache-madlib-1.11-bin-Linux.rpm'
gpg: Signature made Mon May 1 14:42:16 2017 PDT using RSA key ID 28D2C789
gpg: Good signature from "Rashmi Raghu (CODE SIGNING KEY) <rashmiraghu@apache.org>"
$ gsha512sum --check apache-madlib-1.11-bin-Linux.rpm.sha512
apache-madlib-1.11-bin-Linux.rpm: OK

Build is successful (Refer to the installation guide for build instructions)

Check Jenkins build here to make sure it does not show any errors: https://ci-builds.apache.org//job/Madlib/job/madlib-build/

LICENSE and NOTICE files are correct and dependency licenses are acceptable
- LICENSE and NOTICE files at the root of the artifact directory must only reflect the contents of the artifact in which they are contained.
- See:
  - LICENSE file requirements
  - LICENSE requirements for distribution artifacts with multiple licenses
  - NOTICE file requirements (Check Copyright year)
  - Apache Legal
  - Acceptable and Unacceptable Dependency Licenses

All source files have license headers where appropriate, RAT checks pass

$ mvn apache-rat:check

The provenance of all source files is clear (ASF or software grants)

Commit artifacts to Apache dist site

The Apache dist dev site for MADlib is located at: https://dist.apache.org/repos/dist/dev/madlib/

Uploading to this site is via Subversion.

Retrieve the subversion dev madlib repo
Example: svn checkout https://dist.apache.org/repos/dist/dev/madlib/ --username=<your apache user id>
Create a local folder for the release (e.g. 1.11.RC1) in svn. We use apache's distribution repo: https://dist.apache.org/repos/dist/dev/madlib/
Move the files into the release folder on local disk
svn add <release folder>
Commit artifacts:
Example: svn commit -m 'adding 1.11 RC1 candidate release artifacts' --username=<your apache user id>

Create a release candidate for MADlib user docs

The voting email needs to point to the release candidate user docs which are located at https://github.com/apache/madlib-site/tree/asf-site

Create a folder called rc in madlib-site/docs
Run make doc on the release tagged madlib source code

cp -r /path/to/madlib/build/doc/user/html/* /path/to/madlib-site/docs/rc/

Commit the changes to the asf-site branch of madlib-site repo.
While sending out the voting email, include http://madlib.apache.org/docs/rc/index.html as the documentation URL for the release candidate.

...

Vote on the Release

General information regarding the Apache voting process can be found here: http://www.apache.org/foundation/voting.html.

Once the release candidate has been created, validated and the artifacts have been uploaded to the Apache dist site, it is time to have the community vote on the release.

Apache MADlib Community Vote

The MADlib user and developer communities have to vote on every release. The release manager must send out an email to the user and dev mailing lists calling for the vote (link to the example is below). A period of 3 business days is the usual time window for the vote. There are three voting options for the community members to choose from:

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

Please see the Apache voting process site for information on how many +1 votes are needed, what to do in case of -1 votes and for any clarifications to the voting process.

Example email to the community calling for the vote can be found in Apache mail archives site here.

Once the community vote has been completed, the release manager must send out an email to the user and dev mailing lists with the results of the vote. If other scenarios arise in the voting process, please refer to experienced community members or other similar projects for guidance on next steps.

Example email to the community with the results of the vote.

Incubator PMC Vote

Once the community vote has been successfully completed and results have been sent to the community, a round of voting by the Incubator PMC is required. The Incubator PMC (or IPMC) oversees all Apache projects in Incubating state. This vote is not needed once the project reaches Top Level status (TLP status).

The release manager must send out an email (link to an example is below) to the general@incubator.apache.org mailing list calling for the IPMC vote. A period of 3 business days is the usual time window for the vote.

~~Example email to the Incubator PMC calling for their vote on the release candidate.~~

In addition to the above example email, it is also recommended to include this link to the licensing guidance from the ASF when calling an IPMC vote, because it describes the guidance from the ASF regarding MADlib's particular licensing history. This is to make it easier for IPMC members who are reviewing the release and may not be familiar with MADlib's license history and transition to the ASF.

After the IPMC voting has been successfully completed, the release manager must send an email to general@incubator.apache.org with the results of the vote. At this point the release candidate is ready to become GA.

~~Example email to the Incubator PMC with the results of the vote.~~

...

Publishing, distributing and announcing the Release

General Apache information regarding announcing a release may be found here.

Once the release candidate has successfully passed through the voting processes, it is ready to be GA.

...

Move the source, binaries and corresponding signature files from staging (dev) folder to the release dist site: https://dist.apache.org/repos/dist/release/madlib/ . Use the svn mv command. Example below:
svn mv https://dist.apache.org/repos/dist/dev/madlib/1.12.RC1/ https://dist.apache.org/repos/dist/release/madlib/1.12/
Remove old releases from the dev dist sites
1. Retrieve the subversion release madlib repo if you have not done so already
  Example: svn checkout

1. https://dist.apache.org/repos/dist/dev/

...

Please vote accordingly:
[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

...

1. madlib/ --username=<your apache user id>
2. Delete the folders from local working copy using svn delete <folder to delete>.
  E.g. svn delete 1.12.RC1/
3. Commit the deletions: svn commit -m 'Removing 1.12 RC releases' --username=<your apache user id>
Update the user docs link to point to the correct version of the docs and also update any version numbers / links in the page content: http://madlib.apache.org/docs/latest/. Update the MADlib website ... review previous release commits for details:
1. Upload latest release documentation (including docs/latest symlink)
2. Update Download page
3. Upload latest design.pdf
4. Update MADlib home page with release news

Apply release tag referencing git hash representing final release candidate:

git tag -u 57325522 --sign rel/v1.12 -m "Apache MADlib 1.12" 46795de0254d2cb7755ee9336be5fef2a187e8c9
If the -u option doesn't work, then you can also try updating the global git config with your key (It might also be possible to update just the local git config instead of the global config but we haven't tried doing that)
git config --global user.signingkey <KEY>
git tag --sign rel/v1.12 -m "Apache MADlib 1.12" 46795de0254d2cb7755ee9336be5fef2a187e8c9

```
git push upstream <your release tag>
```

In the asf-site branch of madlib-site repo,
1. git mv the content of docs/rc folder into the latest release folder.
2. Update the latest symlink to point to the latest release folder.
After doing the above change, wait for at least 24 hours and then announce the release on announce@apache.org, user@madlib.apache.org and dev@madlib.apache.org mailing lists. See example email of past announcement.

...

Create PostgreSQL Extension Network Release

Artifacts are uploaded to the Apache MADlib extension product location on the PostgreSQL Extension Network (PGXN): https://pgxn.org/dist/madlib/ . Please do this only after there is an official Apache release.

Here are the general steps (used for 1.12 release) on mac os::

git clone git@github.com:apache/madlib.git
cd madlib
git branch MADLIB-1.12 rel/v1.12
git checkout MADLIB-1.12
mkdir build; cd build
cmake ..
make pgxn
Upload Release through PGXN Manager at https://manager.pgxn.org (request credentials from dev list). The built artifact will reside in deploy/PGXN/madlib-pgxn-1.12.0.zip in your build directory.

Verification steps:

sudo easy_install pgxnclient
sudo chmod a+w /usr/local
sudo rm -rf /usr/local/madlib
MAKEFLAGS=1 pgxn install madlib (see Installation Guide#PGXNInstallingfromPGXN(PostgreSQL) for more details)
dropdb madlibtest; createdb madlibtest; /usr/local/madlib/bin/madpack -s madlib -p postgres install
/usr/local/madlib/bin/madpack -s madlib -p postgres install-check

...

Miscellaneous

Some of the content of this page came from the Apache HAWQ project, which is another good guide for release process: https://cwiki.apache.org/confluence/display/HAWQ/Release+Process%3A+Step+by+step+guide

Archived Instructions

As of version 1.19.0, MADlib releases do not provide convenience binaries. The steps to create them are kept in this section in case this decision is reversed or users would like to create such packages for personal use.

Create convenience binaries (rpm, deb and dmg files)

Creating rpm package - CentOS 6 (GPDB 4.3, 4.3 Orca, Postgres 9.5, 9.6)

Build MADlib and rpm package

Example:

cmake -DGREENPLUM_4_3ORCA_PG_CONFIG=/usr/local/gpdb-4.3.10.0-ORCA/bin/pg_config \
-DGREENPLUM_4_3_PG_CONFIG=/usr/local/gpdb-4.3.0.0/bin/pg_config \
-DPOSTGRESQL_9_6_PG_CONFIG=/usr/local/postgresql-9.6/bin/pg_config \
-DPOSTGRESQL_9_5_PG_CONFIG=/usr/local/postgresql-9.5.0/bin/pg_config \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=/usr/local/madlib

Creating rpm package - CentOS 6 (GPDB 5)

Identify build docker image (repository and tag) to use for build by
reviewing the resource named "centos-gpdb-dev-6" in the GPDB 5
Concourse pipeline file.

pipeline file: https://raw.githubusercontent.com/greenplum-db/gpdb/master/concourse/pipelines/gpdb_master-generated.yml

Example:

repo: pivotaldata/centos-gpdb-dev
tag: 6-gcc6.2-llvm3.7

Retrieve latest greenplum 5 release rpm from Pivotal Network
(https://network.pivotal.io/). A free account can be created to
retrieve the Greenplum 5 rpm artifact.

Product: Pivotal Greenplum
Release: 5.0.0 (latest release)

Example:

Release Download Files: Greenplum Database 5.0.0-beta.6 RPM for RHEL 6
File downloaded: greenplum-db-5.0.0-beta.6-rhel6-x86_64.rpm

Copy Greenplum 5 rpm and Apache MADlib source release tarball into directdory (/opt/downloads) which will be mounted into docker container.

Example:

cp greenplum-db-5.0.0-beta.6-rhel6-x86_64.rpm /opt/downloads
cp apache-madlib-1.11-src.tar.gz /opt/downloads

Start Docker container in which to buid

Example:

docker run -it --rm -v /opt/downloads:/tmp/downloads pivotaldata/centos-gpdb-dev:6-gcc6.2-llvm3.7 /bin/bash

Build MADlib and rpm package

Example:

yum install -y /tmp/downloads/greenplum-db-5.0.0-beta.6-rhel6-x86_64.rpm tar xf /tmp/downloads/apache-madlib-1.12-src.tar.gz
cd apache-madlib-1.12-src
mkdir build; cd build

cmake -DGREENPLUM_5_PG_CONFIG=/usr/local/greenplum-db-5.0.0_beta.6/bin/pg_config \
-DCMAKE_INSTALL_PREFIX=/usr/local/madlib \
-DCMAKE_BUILD_TYPE=Release \ ..make
make install
make package
mv madlib-1.12-Linux.rpm apache-madlib-1.12-bin-Linux-GPDB5beta6.rpm

This will generate a file (in the current working directory) with a name similar to madlib-1.12-Linux.rpm. For convenience binary purposes, the file must be renamed to apache-madlib-1.12-bin-Linux-GPDB5beta6.rpm (last step above).

Install and test the MADlib rpm following standard procedures (NOTE: To ensure a clean installation directory, remove /usr/local/madlib prior to installing and testing the rpm).

Creating dmg package - macOS (Postgres 9.4, 9.5 and 9.6)

Required software to create dmg packages

Operating System: macOS Sierra: 10.12.6 (16G29)

PackageMaker.app (copied from contents of dmg listed below into your Applications directory)

Available for download from Apple Developers site
Package: Auxiliary Tools for Xcode - Late July 2012
File: xcode44auxtools6938114a.dmg

Build Postgres versions

For release purposes, you will need to identify the versions of postgres that the release candidate supports. In order to build, you will need to have one installation directory for each supported version of postgres. Download the latest source tarballs for each version from https://www.postgresql.org/ftp/source/. Extract, configure, build, test and install each version.

See this page for list of versions of postgres supported by released versions of MADlib

Example:

wget https://ftp.postgresql.org/pub/source/v9.6.4/postgresql-9.6.4.tar.gz
tar xf postgresql-9.6.4.tar.gz cd postgresql-9.6.4 ./configure --with-python --prefix=/usr/local/pgsql964
make
make check
make install

Repeat for each supported Postgres version.

Build MADlib and dmg package

Perform MADlib release build referencing each Postgres <pg install dir>/bin/pg_config version to be supported during the cmake configuration step:

Example (from source directory):

mkdir build
cd build
cmake -DPOSTGRESQL_9_6_PG_CONFIG=/usr/local/pgsql964/bin/pg_config \
-DPOSTGRESQL_9_5_PG_CONFIG=/usr/local/pgsql958/bin/pg_config \
-DCMAKE_BUILD_TYPE=Release \
-DCMAKE_INSTALL_PREFIX=/usr/local/madlib \
..

make
make install
make package mv madlib-1.12-Darwin.dmg apache-madlib-1.12-bin-Darwin.dmg

This will generate a file (in the current working directory) with a name similar to madlib-1.12-Darwin.dmg. For convenience binary purposes, the file must be renamed to apache-madlib-1.12-bin-Darwin.dmg (last step above).

Install and test the MADlib dmg following standard procedures (NOTE: To ensure a clean installation directory, remove /usr/local/madlib prior to installing and testing the dmg).

Creating deb package - Ubuntu-16 (Postgres 9.6)

If a local Ubuntu environment with Postgres is not available, obtain necessary docker image with postgres using:

   docker pull madlib/postgres_9.6:latest

Follow instructions in https://github.com/apache/madlib#development-with-docker to use the docker container.

Once in the Ubuntu environment, example to build deb package (from source directory):

Note: If the pg_config file is not in the default location, we can specify it as a parameter in cmake using `-DPOSTGRESQL_9_6_PG_CONFIG=<pg_config location>`

mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release \
..

make
make install
make package mv madlib-1.15.1-Linux.deb apache-madlib-1.15.1-bin-Linux.deb

Once 72 hours has passed (which is generally preferred) and/or at least three +1 (binding) votes have been cast with no -1 (binding) votes, send an email closing the vote and pronouncing the release candidate a success. Please use the subject:[RESULT][VOTE]: Apache HAWQ <release version> Release

The Apache HAWQ <release version> vote is now closed and has
passed as follows:

[number] +1 (binding) votes
[number] -1 (binding) votes

A vote Apache HAWQ <release version> will now be called on
general@incubator.apache.org.

Incubator PMC Vote

Once the candidate release vote passes on dev@hawq.apache.incubator.org, call a vote on IMPC general@incubator.apache.org with an email a with subject: [VOTE]: Apache HAWQ <release version> Release and a body along the lines of:

The PPMC vote for the Apache HAWQ <release version> release has
passed. We kindly request that the IPMC now vote on the release.

The PPMC vote thread is located here: <link to the dev voting thread>

The artifacts can be downloaded here:

https://dist.apache.org/repos/dist/dev/incubator/hawq/release/<release number>

The artifacts have been signed with Key : <ID of signing key>

All JIRAs completed for this release are tagged with 'FixVersion
= <release version>'. You can view them here: <insert link to the
JIRA release notes>

Please vote accordingly:

[ ] +1, accept as the official Apache HAWQ <release number> release
[ ] -1, do not accept as the official Apache HAWQ <release number> release because...

The vote will run for at least 72 hours.

If any -1 (binding) votes are entered, then address them such that the voter changes their vote to a +1 (binding) or cancel the vote, fix the issues, and start over with Prepare Tarballs (including re-voting within the Apache HAWQ community on dev@hawq.apache.incubator.org).

Once 72 hours has passed (which is generally preferred) and/or at least three +1 (binding) votes have been cast with no -1 (binding) votes, send an email closing the vote and pronouncing the release candidate a success. Please use the subject: [RESULT][VOTE]: Apache HAWQ <release version> Release

The Apache HAWQ <release version> vote is now closed and has
passed as follows:

[number] +1 (binding) votes
[number] -1 (binding) votes

The Apache HAWQ (incubating) community will proceed with the release.

Publishing and Distributing Release

Finalizing your tag
switching to master branch

git tag -s rel/v{version} <commit SHA> -m "Apache HAWQ(incubating) {version) release (<other comments>)"

Info

title	Sign your release tag

You need to configure your git user signing key first before you can sign a tag.

git config --global user.signingkey <Your secret key SHA>

Push your tag to remote (origin)
```
git push origin rel/v{version}
 
```

Move tarballs from staging (dev) folder to release location:

svn mv https://dist.apache.org/dist/dev/incubator/hawq/{version}.RC#/ https://dist.apache.org/dist/release/incubator/hawq/{version}

Info

title	Commit Message

As if you put https URL in svn commands, it'll commit automatically. A text editor will popup for you to edit commit message, put something like: "Release Apache HAWQ (incubating) {{version}}"

Add download link on hawq website: http://hawq.apache.org/
Go to http://issues.apache.org/jira/browse/hawq to release the specific version (need admin permission, under "Version")
Update the news on http://incubator.apache.org/projects/hawq.html.
Add the document for the version into the hawq website and modify the link if needed. (https://github.com/apache/incubator-hawq-site)

Announce the Release

Send an email to announce@apache.org, general@incubator.apache.org, and dev@hawq.apache.incubator.org with the subject: [ANNOUNCE] Apache HAWQ <release number> Release and a body along the lines of:

Apache HAWQ (incubating) Project Team is proud to announce Apache
HAWQ <release version> has been released.

Apache HAWQ (incubating) combines exceptional MPP-based analytics
performance, robust ANSI SQL compliance, Hadoop ecosystem
integration and manageability, and flexible data-store format
support, all natively in Hadoop, no connectors required. Built
from a decade’s worth of massively parallel processing (MPP)
expertise developed through the creation of the Pivotal
Greenplum® enterprise database and open source PostgreSQL, HAWQ
enables to you to swiftly and interactively query Hadoop data,
natively via HDFS.

...

All changes:
https://cwiki.apache.org/confluence/display/HAWQ/HAWQ+Release+2.1.0.0-incubating+Release

...

Apache HAWQ (incubating) is an effort undergoing incubation at The
Apache Software Foundation (ASF), sponsored by the name of Apache
Incubator PMC. Incubation is required of all newly accepted
projects until a further review indicates that the
infrastructure, communications, and decision making process have
stabilized in a manner consistent with other successful ASF
projects. While incubation status is not necessarily a reflection
of the completeness or stability of the code, it does indicate
that the project has yet to be fully endorsed by the ASF.

General Apache information regarding announcing a release may be found here.

Miscellaneous

Much of the content and organization of this page came from the Apache HAWQ project: https://cwiki.apache.org/confluence/display/HAWQ/Release+Process%3A+Step+by+step+guide

...

Page tree

Page History

Versions Compared

Old Version 4

New Version Current

Key

Table of Contents

Preliminaries

Apache Release Documentation

Permission requirements

Apache Release Documentation

Code Signing Key

Ensure JIRA Issues are Appropriately Tagged for the Release

Creating and Validating the Release Candidate

Prepare Tarballs

Prepare rpm and dmg binaries

Sign the Release Candidate

Create the Release Candidate

Prepare Release Notes

Prepare Tarballs

Sign the Release Candidate

Validate the Release Candidate

Commit artifacts to Apache dist site:

Vote on the Release

Apache HAWQ Community Vote

Commit artifacts to Apache dist site

Create a release candidate for MADlib user docs

Vote on the Release

Apache MADlib Community Vote

Incubator PMC Vote

Publishing, distributing and announcing the Release

Create PostgreSQL Extension Network Release

Miscellaneous

Archived Instructions

Create convenience binaries (rpm, deb and dmg files)

Creating rpm package - CentOS 6 (GPDB 4.3, 4.3 Orca, Postgres 9.5, 9.6)

Creating rpm package - CentOS 6 (GPDB 5)

Build MADlib and rpm package

Creating dmg package - macOS (Postgres 9.4, 9.5 and 9.6)

Required software to create dmg packages

Build Postgres versions

Build MADlib and dmg package

Creating deb package - Ubuntu-16 (Postgres 9.6)

Incubator PMC Vote

Publishing and Distributing Release

Announce the Release

Miscellaneous