= Release Guidelines = == Versioning scheme == We are using the following versioning scheme: 'master' branch has all features, bugfixes and other things. Numeration is 'a.b.c'. For example, numeration of 'master' tags are: * 4.7.0 * 4.7.1 * 4.7.2 * ... Period of releases: typically twice a year (spring and autumn) unless a serious issue is found. == Pre-requisites == * Fresh Fedora VM * {{{dnf build-dep mc}}} * {{{dnf install fakeroot check-devel transifex-client po4a}}} == Release process == '''All next steps described at this page should be mirrored in release tickets step-by-step''' Search previously created ticket with task about next version release (create if ticket not found) and follow by steps while preparing for the release: * prepare repository for release {{{ git fetch git checkout master git reset --hard origin/master git clean -dfx ./autogen.sh mkdir dist; cd dist; ../configure; cd .. }}} * download PO-translations from Transifex.net: {{{./maint/utils/sync-transifex/po-from-transifex.py}}} (see before: [wiki:TxRepoSetup how to set up local tx-repository]) * store translations in git repo {{{ make -C dist/po update-po git add po/*.po git commit -s -m 'Update translations from Transifex' git push origin master }}} * download the hint translations from Transifex.net: {{{./maint/utils/sync-transifex/hints-from-transifex.py}}} * store translations in git repo {{{ git add doc/hints/l10n/mc.hint.* git commit -s -m 'Update hints translations from Transifex' git push origin master }}} * create new NEWS wiki page for next version with empty template. Template may be copied from current NEWS wiki page (without list of tasks and bugreports) * add content of current NEWS wiki page to the doc/NEWS file in git repo. Save it in git: {{{ git add doc/NEWS git commit -s -m 'Update doc/NEWS file' git push origin master }}} * new version in Trac * new milestone in Trac * create new tag in git (see before: [wiki:GpgSetUpForSigningReleases how to set up your gpg key for signing releases]) {{{ git tag -s # keep 'Release' comment git push origin }}} * create tar.(bz2|xz) package files {{{ cd dist; fakeroot make dist-bzip2 && fakeroot make dist-xz }}} * make checksums for archives {{{ sha256sum mc-*tar.* > mc-{version}.sha256 }}} * upload source packages and checksums to the special upload area * developers should download tarballs, verify checksums, compile and install locally; if everything is ok, then developers vote for the ticket {{{ ./configure --prefix=$(pwd)/install make install make check }}} * upload source packages and checksums to {{{scp mc-X.X.XX.* midnightcommander@ftp-osl.osuosl.org:/home/midnightcommander/data}}} (all maintainers have access via pubkeys) * run {{{ssh midnightcommander@ftp-osl.osuosl.org '/home/midnightcommander/trigger-midnightcommander'}}} * update Wiki start page with latest release number * write an announcement: list user visible changes (bugs and features) * create new ticket (type=task, component=adm) for the next release * close ticket for release * close current milestone === Notes: === * Cleanup branch should be named as XXXX_cleanup; where XXXX it's a number of current release ticket. * The cleanup branch should be created by demand and should be voted and merged to main branch ASAP. Don't keep the cleanup branch in development stage longer that it needed. * Activity around cleanup branch should occur in release ticket. * Cleanup branch should be deleted after merging to main branch. Cleanup branch may be recreated with same name with any count of times. * Cleanup branch shouldn't be merged to main branch in a week before release (all changes should be moved to cleanup branch for next release)