Versions Compared

Old Version 2

changes.mady.by.user Frank McQuillan

Saved on

compared with

New Version Current

changes.mady.by.user Orhan Kislal

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Preliminaries

Permission requirements

The following permissions are required to perform release manager duties.

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.

Ensure JIRA Issues are Appropriately Tagged for the Release 

Ensure that all 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

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

  1. Update the wiki with these release notes for the new release
  2. 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

  1. 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
  2. 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 Mac OS):

$ brew install gpg coreutils

$ which gpg gsha512sum
/usr/local/bin/gpg
/usr/local/bin/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

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

  • 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

This document describes how to release Apache MADllib following the ASF release policy.  These tasks are typically performed by the Release Manager (RM).

Give a heads up

The RM should first create list of issues/features and then setup a timeline for release branch point. The time for the day the issue list is created to the release branch point must be at least two weeks in order to give the community a chance to prioritize and commit any last minute features and issues they would like to see in the upcoming release.

The RM should then send the pointer to the umbrella issue along with the tentative timeline for branch point to the developer lists. Any work identified as release related that needs to be completed should be added as a sub task of the umbrella issue to allow users to see the overall release progress in one place.

The RM should then inform users once branch point is created.

To: dev@fineract.incubator.apache.org
Subject: Work on $release release has started
Created a tracking jira (jira#) for the Fineract $release and plan to branch tentatively on $date. 
What would you like to see included?
Thanks, $RM

Sanitize JIRA

Before a release is done, make sure that any issues that are fixed have their fix version setup correctly.

 

project = fineract and resolution = fixed and fixVersion is empty

 

Move the unresolved jiras to the next release

 

 

project = fineract and fixVersion = 0.7.0-incubating and status not in( resolved, done, Accepted, Closed)

 

You can also run the following query to make sure that the issues fixed for the to-be-released version look accurate:

 

project = fineract and fixVersion = '0.7.0-incubating'

 

Finally, check out the output of the JIRA release note tool to see which JIRAs are included in the release, in order to do a sanity check.

Creating Release Artifacts

Communicate with the community

Send an email to developer mailing list(dev@fineract.incubator.apache.org) to notify that you are about to branch. Ask to hold off any commits until this is finished. Send another email after branching is done.

Create a release branch
Clone fresh repository copy

 

% git clone https://git-wip-us.apache.org/repos/asf/incubator-fineract.git
% cd incubator-fineract

 

Check that current HEAD points to commit on which you want to base new  release branch. Checkout particular commit if not.

 

 

% git log # Check current branch history. HEAD should point to commit that you want to be base for your release branch

 

Create a new release branch with name "$Version"

 

% git checkout -b 0.7.0-incubating

 

Push new branch to Apache Fineract repository

 

% git push origin 0.7.0-incubating

 

Add new release notes in Release Folders

(The change list can be swiped from the JIRA release note tool (use the "text" format for the change log). See JIRA Cleanup above to ensure that the release notes generated by this tool are what you are expecting)

Send en email announcing the new release branch
To: dev@fineract.incubator.apache.org
Subject: New release branch 0.7.0-incubating 
I've just created new release branch for upcoming 0.7.0-incubating release. 
Please continue committing to develop branch as usual. 
I'll cherry-pick commits to branch 0.7.0-incubating on per needed basis. Thanks, $RM
Tag release branch

 

% git checkout 0.7.0-incubating
% git tag -a release-0.7.0-incubating -m "Fineract 0.7.0-incubating release"
#Make sure compiles/tests run fine and rat check is fine (% cd fineract-provider, % gradlew clean integrationTest)
% git push origin release-0.7.0-incubating

 

Create source and binary artifacts. The steps are defined in Release Sign
Sanity Check

Make sure the tar and the release branch match

% cd /fineract-release-preparations
% tar -xvf apache-fineract-0.7.0-incubating-src.tar.gz
#Do a fresh clone of the tag
% git clone https://git-wip-us.apache.org/repos/asf/incubator-fineract.git
% cd incubator-fineract/
% git checkout tags/release-0.7.0-incubating
% cd ..
% diff -r incubator-fineract apache-fineract-0.7.0-incubating-src
Make sure code compiles and tests pass on the uncompressed source.
#Make sure prerequisites are met before running these commands
% cd apache-fineract-0.7.0-incubating-src/fineract-provider
% gradlew clean integrationTest (For running integration tests)
% gradlew clean build (For building deploy able war)
% gradlew rat (For RAT checks)
Create signatures and check sums

All release artifacts must be signed. In order to sign a release you will need a PGP key. You should get your key signed by a few other people. You will also need to receive their keys from a public key server.   See the Apache release signing page for more details. Please follow the steps defined in Release Sign

Verifying a release candidate

Following are the typical things we need to verify before voting on a release candidate. And the release manager should verify them too before calling out a vote.

  • Make sure release artifacts are hosted @https://dist.apache.org/repos/dist/dev/incubator/fineract/
  • Release candidates should be in format apache-$project-$version.tar.gz 
  • Verify signatures and hashes.  You may have to import the public key of the release manager to verify the signatures. (gpg --recv-key <key id>)
  • git tag matches the released bits (diff -rf)
  • Can compile successfully from source
  • Verify DISCLAIMER, NOTICE and LICENSE (year etc)
  • All files have correct headers (Rat check should be clean - gradlew rat)
  • No jar files in the source artifacts
 Running the vote

Voting has to be done on dev@fineract.incubator.apache.org and . You can close the vote after voting period expires and you accumulate sufficient votes.

 Call for voting on dev list (PMC)

...

The Apache dist dev site for MADlib is located at: 

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

...

Upon receiving 3 +1s from the PMC, reply to the voting thread and prefixing [RESULT] to the subject line with the results.

To: dev@fineract.incubator.apache.org
Subject: [RESULT][VOTE] [APACHE FINERACT] 0.7.0-incubating for release
Voting is now closed and has passed with the following tally,
Binding +1s: Justin McLean,Jim Jagielski,John D Ament
Non binding +1s: Shaik Nazeer, Adi Raju, Markus, Myrle
Thanks to everyone who voted! I'll continue with the rest of the release process.
$RM
Call for voting on dev list (IPMC)

...

madlib/

Uploading to this site is via Subversion.

  1. Retrieve the subversion dev madlib repo
    Example: svn checkout https://dist.apache.org/repos/dist/dev/madlib/ --username=<your apache user id>
  2. 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/
  3. Move the files into the release folder on local disk
  4. svn add <release folder>
  5. 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

  1. Create a folder called rc in madlib-site/docs

  2. Run make doc on the release tagged madlib source code

  3. cp -r /path/to/madlib/build/doc/user/html/* /path/to/madlib-site/docs/rc/
  4. Commit the changes to the asf-site branch of madlib-site repo.
  5. 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.

  1. Move the source, binaries and corresponding signature files from staging (dev) folder to the release dist site: https://dist.apache.org/repos/dist/

...

  1. release/

...

  1. madlib/

...

  1.  . Use the svn mv command. Example below:
    svn mv https://dist.apache.org/repos/dist/dev/

...

  1. madlib/

...

  1. 1.

...

  1. 12.RC1/ https://dist.apache.org/repos/dist/release/madlib/1.12/

  2. 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 https://dist.apache.org/repos/dist/dev/

...

Upon receiving 3(binding) +1s from the IPMC, reply to the voting thread and prefixing [RESULT] to the subject line with the results. The binding votes from dev voting will be carried for general voting also. For example if we get 1 binding vote on dev listing and 2 binding votes on general listing, the RM can pass the release with 3 binding votes. 

To: general@incubator.apache.org
CC: dev@fineract.incubator.apache.org
Subject: [RESULT][VOTE] [APACHE FINERACT] 0.7.0-incubating for release
Voting is now closed and has passed with the following tally,
Binding +1s: Justin McLean,Jim Jagielski,John D Ament
Thanks to everyone who voted! I'll continue with the rest of the release process.
$RM
 Rolling out the Release

Close JIRA version

You need to close the release in JIRA so that everyone knows that your version should not be used as "fixVersion" for new bugs. Go to JIRA "Administer project" page and follow "Versions" in left menu. Table with list of all releases should appear, click on additional menu on the right of your release and choose "Release" option. Submit release date and you're done.

Upload the artifacts

In order to release you have to checkout release repository located on https://dist.apache.org/repos/dist/release/incubator/fineract and add release artifacts there.

 

svn co https://dist.apache.org/repos/dist/release/incubator/fineract fineract-incubating-release
cd fineract-incubating-release
mkdir 0.7.0-incubating/
cp $source_to_your_artifacts 0.7.0-incubating/ svn add 0.7.0-incubating/

 

Announce the release

Send an email to announce@apache.org (the from: address must be @apache.org). For example,

...

    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>
  2. 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

  3. Apply release tag referencing git hash representing final release candidate:

    1. 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
    2. git push upstream <your release tag>
  4. 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.
  5. 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::

  1. git clone git@github.com:apache/madlib.git
  2. cd madlib
  3. git branch MADLIB-1.12 rel/v1.12
  4. git checkout MADLIB-1.12
  5. mkdir build; cd build
  6. cmake ..
  7. make pgxn
  8. 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:

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

...

Miscellaneous

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

Finally update the website with latest release details downloads. Code is available at Website Code. Apache Fineract website reflects the code present in asf-site branch of https://git-wip-us.apache.org/repos/asf/incubator-fineract-site.git. Any change committed on master branch of https://git-wip-us.apache.org/repos/asf/incubator-fineract-site.git should be merged with asf-site branch to reflect the change on Fineract website.

...