= 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 by command {{{maint/utils/sync-transifex/po-from-transifex.py}}} (see before: [wiki:TxRepoSetup how to set up local tx-repository]) 
 * store translations in git repo by following commands:
{{{
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 by command: {{{MC_SOURCE_ROOT_DIR=$(pwd) maint/utils/sync-transifex/mc.hint-fromTransifex.sh}}}
 * store translations in git repo by following commands:
{{{
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 by following commands:
{{{
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 by command (see before: [wiki:GpgSetUpForSigningReleases how to set up your gpg key for signing releases])
{{{
git tag -s <version>
# keep 'Release' comment
git push origin <version>
}}}
 * 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 command: {{{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)