mirrors/mc
1
0
Fork 0
mirror of https://github.com/MidnightCommander/mc synced 2024-12-22 04:22:34 +03:00
Code Issues Packages Projects Releases Wiki Activity

Update the 'release procedure' file.

Browse Source 
Signed-off-by: Slava Zanko <slavazanko@gmail.com>
This commit is contained in:
Slava Zanko 2013-04-09 00:54:42 +03:00
parent 1c6d859629
commit 57116bca6e
1 changed files with 46 additions and 41 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

87
maint/docs/RELEASE_PROCEDURE
View File

@ -1,53 +1,58 @@
This document describes step by step the release procedure of GNU
Midnight Commander.
# ---------------------------------------------------------------------------------------
${dotted_version} shall be replaced by something like 4.6
${underscore_version} shall be replaced by something like 4_6
Scenario #1
As developer
I Want To prepare release files for review by developers
=== day 0 (translator's prerelease) ===
Given have latest version from 'git tag' output (saved to ${last_version})
and latest version is increased (saved to ${next_version})
* Check out a fresh copy from the CVS repository.
When I want To: prepare to release
* Update the translation files NOT to contain line number information.
Commit them.
* Tag the CVS tree as "MC_${underscore_version}_translators".
* Update the translation files to contain line number information.
DON'T commit them.
* Run "make dist".
* Upload the distribution tarballs and the individual translation files
somewhere where the translators can download it.
* Announce the availibility of the translator's prerelease on mc-devel.
Inform the translators of the prerelease.
Inform the developers of a fourteen-day "feature-freeze".
Then I Should: sync PO translations from Transifex.net
and sync mc.hint translations from Transifex.net
and create new NEWS wiki page for ${next_version} with empty template
and add content of NEWS-${last_version} wiki page to the doc/NEWS file in git repo
and create new tag '${next_version}' in git
and add new version '${last_version}' in Trac
and add new milestone '${next_version}' in Trac
and create tar.(bz2|xz) package files
and create checksums for archives:
and upload source packages and checksums to the special upload area
=== day 11 (reminder) ===
# ---------------------------------------------------------------------------------------
* announce a reminder on mc-devel that the release will occur in three
days.
Scenario #2
As developer
I Want To review files prepared for release
=== day 14 (official release) ===
Given have prepared files for review
* Review the English version of the manual and fix it if necessary.
Update the date and the version number in the .TH macro of the English
manual pages.
* Update the NEWS file to contain all user-visible changes.
* Set the version number in configure.ac to "${dotted_version}".
Commit it.
* Update the translation files NOT to contain line number information.
Commit them.
* Run the test suites maint/mctest and maint/mc-test and make sure
all warnings are ok.
* Tag the CVS tree as "MC_${underscore_version}_release".
* Create a CVS branch "MC_${underscore_version}".
* Run "make dist".
* Upload the resulting tarballs to the Savannah repository.
* Announce the new release on the mc-devel and mc mailing lists.
* Update the homepage.
When I Want To: release next version
=== post-release actions ===
Then I Should: download archives from special upload area
and download checksums for archives from special upload area
and verify checksums and archives
and unpack arhives
and configure with default parameters
and run 'make all install DESTDIR=/tmp/mc-release'
and if everything is okay, keep vote in release ticket
* Create binary packages from the uploaded tarballs as necessary.
# ---------------------------------------------------------------------------------------
=== back to work ===
Scenario #3
As developer
I Want To complete the release procedure
* Discuss milestones for the next release on the mc-devel list.
Given have votes from developers
When I Want To: complete the release
Then I Should: upload source packages and checksums to http://www.midnight-commander.org/downloads
and update Wiki start page with ${next_version} release number
and write an announcement in mc-dev and mc-users mailists: list user visible changes (bugs and features)
and close milestone with '${last_version}' version
and create new ticket (type=task, component=adm) for the next release
and close ticket for release.
# ---------------------------------------------------------------------------------------