Release Process
You are viewing an old version of this article. View
the current version here.
Procedures for doing a MariaDB release
This page documents the release process for MariaDB.
Release Steps
- Commit fixes into the appropriate tree until Buildbot looks OK
- The Release Coordinator adds a release tag to the release tree (e.g. tag:mariadb-5.2.5 for the 5.2.5 release, see note 1 below for sample command line)
- The release coordinator notifies the following of the tag, the build number
(see Note 6, below), and that the tree is ready for release:
- The Maria Docs team
(
maria-docs [at] lists (dot) launchpad (dot) net
) - The Maria Dev team
(
maria-developers [at] lists (dot) launchpad (dot) net
)rsync.osuosl.org::mariadb/mariadbrsync.osuosl.org::mariadb/mariadb - The community team (
community [at] askmonty (dot) org
)
- The Maria Docs team
(
- The docs team verifies with the release coordinator that all three merges are done (MariaDB 5.1-5.5; mysql, xtradb)
- The Builbot buildslaves build packages and the release coordinator informs the Docs team when they are ready to be copied over
- Someone with the proper access logs in to the osuosl mirror and updates the
get.sh script with the correct values and then runs the script. This script
uploads the source tarball, the generic Linux binaries, and the windows
builds.
- Note: For MariaDB Galera Cluster releases:
- Rename the source tar.gz file to have '-galera' in the name prior to uploading it to the mirrors. Don't forget to regenerate the md5sum for the file in md5sums.txt.
- If the galera package has been updated, rebuild as per instructions here (Debian/Ubuntu). Add the newly built packages to
/home/dbart/galera/
and move the old packages to/home/dbart/galera/old/
- Note: For MariaDB Galera Cluster releases:
- Someone on the release team creates the Debian and Ubuntu repositories then uploads them to osuosl. (See note 4)
- Someone on the release team creates the YUM repositories and then uploads them to osuosl. (See note 5)
- Once all files are uploaded to osuosl, run the trigger script, to push the
new files out to the public server:
./trigger-mariadb
- Packages get uploaded to mirrors (this happens automatically as soon as the above trigger script is run)
- The Docs team imports the new release into the MariaDB Download system
- The Docs team fills in, edits, and finishes the release notes and changelog
pages and removes the
unreleased
template (if it is there) about the information on the page being about an unreleased version - 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)
- Once all packages have been mirrored, the Docs team 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.
- If this is a MariaDB 5.3 release, copy the CentOS 5 MariaDB-shared-5.3 rpms (x86_64 and i386) over to /media/backup/archive/rpm/ on hasky and update the sym-links in that folder to point at them.
- update the MacOS brew file mariadb.rb with the latest version and sha1sum, push it to github, and issue a pull request (this assumes you already have a fork of the brew upstream and have it all set up)
- 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.
- Announce the release
- Consolidate release announcements when possible (e.g. one release email for a set of 5.1/5.2/5.3 releases in a single week).
- The Docs team updates (if applicable):
- the releases RSS feed (also expire the news entry for the previous release)
- If the release is the current stable branch:
- Mark the Release Notes as featured in the KB admin interface
- Unmark the previous release's release notes as featured
- the banners on the following websites:
- the applicable "What is MariaDB x.x" page with the new version
- the MariaDB Download Banner
- 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 community team 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, send the release announcement through PR Newswire (Colin does this now)
Notes:
- Tagging releases
- bzr: Here is an example bzr command line to make the tag:
bzr tag --revision=3402 --directory=lp:~maria-captains/maria/5.3 mariadb-5.3.4
- git: Here is an example git command line to make the tag:
git tag <tagname> <commit-hash> ; git push origin <tagname>
- bzr: Here is an example bzr command line to make the tag:
- 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
- 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
- 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 git@github.com: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: #------------------------------------------------------------------------------ major=5.5 minor=41 cd ~/src/mariadb/server git checkout origin/${major} git fetch --all --tags 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" mariadb-${major}.${minor}.. >> tmp.creole #------------------------------------------------------------------------------ # old 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).
- Creating Debian and Ubuntu Repositories: 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
- Signing RPM Packages and Creating the YUM repositories:
- 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-buildnum
- 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.
- Prior to beginning, ensure that you have a .rpmmacros file with the following contents (replace '<keyname>' with the actual key name):
- Determining build numbers for releases: Build numbers come from
Buildbot. To get the build number for a specific buid, e.g. for MariaDB 5.2
builds:
- Look at the columns here. The headers across the top list the branch (5.2 in this case) and the revision numbers for the last five builds.
- Pick the column that corresponds to the revision number with the with the correct release tag (you can view the tags and revision numbers on Launchpad).
- Select one of the builds in the correct column and look for the property
"tarbuildnum". This is the
build-###
directory you want.
Comments
Comments loading...
Content reproduced on this site is the property of its respective owners,
and this content is not reviewed in advance by MariaDB. The views, information and opinions
expressed by this content do not necessarily represent those of MariaDB or any other party.