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
• yum build-dep mc
• yum install fakeroot check-devel po4a

macOS

brew install autoconf autoconf-archive automake libtool pkg-config check

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 (see before: how to set up local tx-repository)

  ./maint/utils/sync-transifex/po-from-transifex.py
  

• 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

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

  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: 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 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)