Release Process [obsolete]
Contents
- Release Steps
- Notes
- Note 1: Tagging releases and bumping the VERSION
- Note 2: Creating md5sums
- Note 3: Obtaining info for Changelog and Release Notes (BZR):
- Note 4: Obtaining info for Changelog and Release Notes (Git):
- Note 5: Creating Debian and Ubuntu Repositories:
- Note 6: Signing RPM Packages and Creating the YUM repositories:
- Note 7: Determining build numbers for releases:
- See also
This page documents the release process for MariaDB.
Release Steps
- Developers commit fixes/features/etc into the appropriate tree until Buildbot looks OK (as determined by the Release Coordinator)
- The Buildbot buildslaves build packages and the Release Coordinator informs the Release Manager by creating a TODO in Jira and maybe posting a message in Slack
- Buildbot builds the packages and when they are ready, or nearly ready, the
Release Coordinator notifies the following of the tree, revision, and build
number (tarbuildnum, see
Note 7, below):
- The Release Manager (dbart)
- The Maria Dev team
(
maria-developers [at] lists (dot) launchpad (dot) net
) - The community team (
community [at] mariadb (dot) org
)
- The Release Manager preps initial release notes and changelog pages for the release and sends these out to the MariaDB packagers list and the marketing team.
- The Release Manager logs in to the buildmaster and runs the
prep
script. This script is found in the mariadb.org-tools repo on GitHub under therelease
directory. The script prepares the release directory which contains the generic Linux binaries, the Windows builds, and the YUM and APT repositories. Notes 5 and 6 describe the basic process for creating repositories, but the script handles the creation automatically.
Run the script with the -h
flag to see the various options. A typical run
of the script looks like the following:
~/src/mariadb.org-tools/release/prep -yl \ -t 10.0 -v 10.0.20 -b 8266 \ -r a6087e7dc1ef3561d8189c8db15e9591d0f9b520
The script relies on a configuration file being present in the home
directory: /.prep.conf
. This file will be created if it doesn't exist,
but it won't have the correct values. An admin can give you a copy of file
with the correct configuration values set.
Note: For MariaDB Galera Cluster releases:
- If the
galera
package has been updated, the MariaDB Galera dev team will provide new galera packages to the Release Manager. These must be added to thegalera
folder in their owngalera-<version>
subfolder, and the prep-release script must be updated accordingly.
- Once the prep script is finished, files are uploaded to osuosl (the prep
script offers to do this automatically) then a trigger script is run on the
osuosl server to push the new files out to the public server:
./trigger-mariadb
- Packages get uploaded to mirrors automatically depending on when they next pull from the osuosl mirror.
- The Release Manager imports the new release into the MariaDB.org Download system and MariaDB.com download system
- The Release Manager, with assistance from the Docs team, fills in, edits,
and finishes the release notes and changelog pages (see
Note 4) and
removes the
unreleased
template (if it is there)
- The Docs team creates release notes and changelog pages for the next release
(so that the developers can fill them in as they work on the release)
- The unreleased banner should be placed on these pages to let users know
that the information on the page is about an unreleased version. The creole
syntax for including the template is:
<<include slug="unreleased">>
- The unreleased banner should be placed on these pages to let users know
that the information on the page is about an unreleased version. The creole
syntax for including the template is:
- The Docs team preps updates to other documentation as necessary
- Check with the Release Coordinator to see if there are any new features that should be added to the series pages (links below)
- The Release Coordinator (or the Release Manager) adds a release tag to the
release tree (e.g.
mariadb-10.1.23
for the 10.1.23 release, see Note 1, below, for sample command lines).
- Once all packages have been mirrored, the Release Manager activates the
new release on the MariaDB Downloads
page and activates any other documentation changes/additions
- Use the "Check Mirrors" feature of the downloads system to check if the files are fully mirrored.
- Check the MariaDB Deprecation Policy page to see if this will be the last release for any platforms. Be sure to mention them in the Release Notes and in the Announce emails. Update the page as necessary. After the release is out, edit the buildbot config to turn them off. Do not remove the VMs.
- If the release is done from the
bb-XXX-release branch
, then for all MDEVs pushed intoXXX
afterbb-XXX-release
was forked:major=10.5
git log bb-${major}-release..${major}
- Change the FixVersion to the next release in Jira for all the MDEVs that show up
- For example, any MDEV in `git log bb-10.5-release..10.5` for the 10.5.4 release should have 10.5.5 in the FixVersion, not 10.5.4
- The Release Manager marks the release as "released" in JIRA. Before doing so, create a follow up release, if it doesn't already exist.
- Announce the release
- Consolidate release announcements when possible (e.g. one release email for a set of 5.5/10.0/10.1 releases in a single week).
- The Release Manager or Docs team updates (as applicable):
- the applicable "What is MariaDB x.x" page with the new version (both the list of releases and the page excerpt)
- Update the 'latest' template for the release, and include it at the top of the previous release's release notes page (e.g. with '
<<include slug="latest-55">>
'): - An IRC op (dbart, etc...) updates the topic in #maria (if release is the current stable)
- The Release Manager announces the release on the announce and maria-discuss mailing lists, and via blogs and other methods (e.g. Facebook, Twitter, Google+, & LinkedIn)
- For major releases, an announcement will also be sent out as a press release
Notes
Note 1: Tagging releases and bumping the VERSION
Here is an example git command line to make the tag and bump the tree to the next version:
main=10.2 cur=38 # minor version of *current* release rev=abc123 # hash of the release commit revision tree=bb-${main}-release # release tree, e.g. bb-10.2-release cd ~/src/mariadb/server # first tag the release git checkout ${tree} git pull git tag mariadb-${main}.${cur} ${hash} ; git push origin mariadb-${main}.${cur} # second bump the VERSION, we do this in the main tree, not the release tree git checkout ${main} git pull git checkout bb-${main}-bumpversion git rebase ${main} vi VERSION # increment the PATCH version number git commit -a -m "bump the VERSION" git push origin while :; do sleep 60;git push origin bb-${main}-bumpversion:${main}; done # watch the output until you start seeing "Everything up-to-date" messages, then Ctrl+c to exit git checkout ${main} git pull git checkout bb-${main}-bumpversion git rebase ${main} git push origin
The bb-*-bumpversion
branches were initially created like so:
cd ~/src/mariadb/server git checkout ${main} git pull git checkout -b bb-${main}-bumpversion git push --set-upstream origin bb-${main}-bumpversion
Note 2: Creating md5sums
Here are the commands I (Daniel) use to create the md5sums of a release:
cd /path/to/dir/with/releases/ release='mariadb-5.2.1-beta' for dir in $(find ${PWD}/${release} -type d); do echo; echo ${dir};cd ${dir};md5sum *;echo;echo;done
Note 3: Obtaining info for Changelog and Release Notes (BZR):
A raw log of all changes can be obtained from bzr as follows:
sourcedir="5.1" oldrelease="mariadb-5.1.44b" newrelease="mariadb-5.1.47" bzr branch --no-tree -rtag:${oldrelease} ${sourcedir} ${oldrelease} bzr branch --no-tree -rtag:${newrelease} ${sourcedir} ${newrelease} cd ${newrelease}/ bzr missing --kb-short --include-merged ../${oldrelease} > /tmp/short.txt bzr missing --kb-long --include-merged ../${oldrelease} > /tmp/long.txt
Assuming that you have kbchangelog bzr plugin, this will generate a list of changes that uses Wiki Creole syntax and is ready to be pasted into the corresponding Changelog page. It might need a little bit of manual polishing, though. if there is no ${oldrelease} then do the following:
cd ${newrelease}/ bzr log --kb-short --include-merged > /tmp/short.txt bzr log --kb-long --include-merged > /tmp/long.txt
Note 4: Obtaining info for Changelog and Release Notes (Git):
A raw log of all changes can be obtained from git as follows:
#------------------------------------------------------------------------------ # Prep (only done once): #------------------------------------------------------------------------------ cd ~/src/mariadb git clone [email protected]:MariaDB/server.git cd server git remote add mysql https://github.com/mysql/mysql-server git remote add tokudb-engine https://github.com/Tokutek/tokudb-engine git remote add tokudb-ft-index https://github.com/Tokutek/ft-index git fetch --all --tags git replace 2a15820e1e 7c240a1b99 git replace 906c8b2794 068416d302 git replace efb32d4644 9cd31bc559 git replace fa7b0180f5 0773c7f422 #------------------------------------------------------------------------------ # Done every time: #------------------------------------------------------------------------------ product=mariadb # or mariadb-galera major=10.1 minor=2 # minor version of *previous* release tree=${major} # sometimes different e.g. 10.0-galera cd ~/src/mariadb/server git checkout ${tree} git pull git fetch --all --tags git log --topo-order ^mysql/5.5 ^tokudb-engine/releases/tokudb-7.5 ^tokudb-ft-index/releases/tokudb-7.5 --pretty=format:"* gitrev:%h%n<<style class=\"datetime\">>%ai<</style>>%n** %s" ${product}-${major}.${minor}.. > tmp.creole # alternate log styling for merges: git log --merges --topo-order ^mysql/5.5 ^tokudb-engine/releases/tokudb-7.5 ^tokudb-ft-index/releases/tokudb-7.5 --pretty=format:"* <<style class=\"datetime\">>gitrev:%h %ai - %s<</style>>" ${product}-${major}.${minor}.. > tmp2.creole # then after copying the contents of tmp.creole into the changelog page rm -v tmp*.creole #------------------------------------------------------------------------------ # old commands #------------------------------------------------------------------------------ # second version without merges git log ^mysql/5.5 ^tokudb-engine/releases/tokudb-7.5 ^tokudb-ft-index/releases/tokudb-7.5 --no-merges --pretty=format:"* gitrev:%h%n<<style class=\"datetime\">>%ai<</style>>%n** %s" ${product}-${major}.${minor}.. > tmp.creole # first version of command git log --first-parent --pretty=format:"* gitrev:%h%n<<style class=\"datetime\">>%ai<</style>>%n** %s" 0f64a92..fdd6c11 > tmp.creole
In the 'old command' example above, 0f64a92..fdd6c11
is the range of the
changelog being generated with 0f64a92 being the last revision of the old
MariaDB release (5.5.41 in the example) and fdd6c11 being the newest revision
in the changelog for the current MariaDB release (5.5.42 in the example).
Note 5: Creating Debian and Ubuntu Repositories:
This note is obsolete. It is being preserved here purely for historical purposes.
Prior to doing this, branch mariadb-tools from Launchpad:
bzr branch lp:mariadb-tools/trunk mariadb-tools
(or update a previously branched copy with "bzr pull").
- Copy the build over to a working directory.
- Run the following commands:
mkdir repo cd repo eval $(gpg-agent --daemon) path/to/mariadb-tools/buildbot/mkrepo-debian.sh debian path/to/build-buildnum path/to/mariadb-tools/buildbot/mkrepo-ubuntu.sh ubuntu path/to/build-buildnum cd ../
- On the osuosl mirror, move the old repo/5.x dir and upload the new repo to repo/5.x
scp -r repo osuosl:data/repo/5.2
- Clean up your working directory by removing the local repo and
build-
###
directories
Note 6: Signing RPM Packages and Creating the YUM repositories:
This note is obsolete. It is being preserved here purely for historical purposes.
- Prior to beginning, ensure that you have a .rpmmacros file with the following contents (replace '<keyname>' with the actual key name):
%_signature gpg %_gpg_path ~/.gnupg %_gpg_name <keyname> %_gpgbin /usr/bin/gpg
- Create a directory for the files based on the major.minor release numbers (for example: 5.5)
- cd into the directory
- run the mkrepo-yum.sh script:
path/to/mariadb-tools/buildbot/mkrepo-yum.sh path to build-tarbuildnum
For 5.1, 5.2, 5.3 releases, you will have to temporarily change the script to just process centos5 and rhel5. Fedora, centos6, and rhel6 only support 5.5 and above. Be sure to revert your changes after running the script.
- at certain points while the script runs you will be prompted for the signing key password
- Upload the files to the primary mirror:
release="mariadb-5.5.24" for dir in $(ls);do rsync -avP ${dir} osuosl:data/${release}/ done
- Upload the files to the YUM repo server:
version="5.5" for dir in $(ls);do rsync -avP ${dir} yum-repo-server:${version}/ done
- Once uploaded, ssh to the yum repo server and move the files to their
proper location, replacing the previous repo
${releasenum}
dir.
Note 7: Determining build numbers for releases:
Build numbers come from Buildbot. To get the build number for a specific buid, e.g. for MariaDB 10.1 builds:
- Look at the columns here. The headers across the top list the branch (10.1 in this case) and the revision hashes for the last few builds.
- Pick the column that corresponds to the revision hash with the with the correct release tag
- Select one of the builds in the correct column and look for the property
"tarbuildnum". This is the
build-###
directory you want.
See also
- MariaDB server release schedule. The table on the right contains dates for the next MariaDB server releases