Last modified 2 months ago
Last modified on 08/23/24 18:58:58
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
Fedora (fresh VM for releases)
yum build-dep mc yum install git-core fakeroot check-devel po4a libX11-devel
macOS
brew install autoconf automake libtool pkg-config check gnu-indent brew install glib libssh2 openssl s-lang
git
git config --global user.name "Yury V. Zaytsev" git config --global user.email "yury@shurup.com"
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'
- check that files can be dowloaded, if not, adjust permissions to 644
- 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)