wiki:ReleaseGuidelines

Version 52 (modified by egmont, 7 years ago) (diff)

update release schedule

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.

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 MC_SOURCE_ROOT_DIR=$(pwd) maint/utils/sync-transifex/po-fromTransifex.sh (see before: how to set up local tx-repository)
  • store translations in git repo by following commands:
    git add po/*.po
    make -C dist/po update-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
    
  • create new tag in git by command (see before: how to set up your gpg key for signing releases?)
    git tag -s <version>
    # keep 'Release' comment
    git push origin <version>
    
  • new version in Trac
  • new milestone in Trac
  • 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 midnightcommander@…/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)
  • close current milestone
  • create new ticket (type=task, component=adm) for the next release
  • close ticket for release

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)