mirrors/mc
1
0
Fork 0
mirror of https://github.com/MidnightCommander/mc synced 2024-12-22 12:32:40 +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 Scenario #1
${underscore_version} shall be replaced by something like 4_6 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. Then I Should: sync PO translations from Transifex.net
Commit them. and sync mc.hint translations from Transifex.net
* Tag the CVS tree as "MC_${underscore_version}_translators". and create new NEWS wiki page for ${next_version} with empty template
* Update the translation files to contain line number information. and add content of NEWS-${last_version} wiki page to the doc/NEWS file in git repo
DON'T commit them. and create new tag '${next_version}' in git
* Run "make dist". and add new version '${last_version}' in Trac
* Upload the distribution tarballs and the individual translation files and add new milestone '${next_version}' in Trac
somewhere where the translators can download it. and create tar.(bz2|xz) package files
* Announce the availibility of the translator's prerelease on mc-devel. and create checksums for archives:
Inform the translators of the prerelease. and upload source packages and checksums to the special upload area
Inform the developers of a fourteen-day "feature-freeze".
=== day 11 (reminder) === # ---------------------------------------------------------------------------------------
* announce a reminder on mc-devel that the release will occur in three Scenario #2
days. 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. When I Want To: release next version
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.
=== 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.
# ---------------------------------------------------------------------------------------