Well, I propose to coordinate the preparation of the 1.7 release, named Eta Carinae. Luis is lacking of time theese days, Garland and Mr Polidor are recluded, so, we have to help and begin the release process with the rest of us.
Here are the reasonnable steps we should conduct, the way we conduct them is an open topic of discussion beetween any all registered contributors (using the word developers is rather diminutive in regard of the diversity of the people in developers list).
1/ Release Cycle Announce
Public announce that The release is now started and can take some days. CVS is under pressure.
- what ? write down an announce and make pages, prepare tools
- where ? mail to tikiwiki-devel at lists.sf.net and tikiwiki-users at lists.sf.net, post article on tikiwiki.org, prepare tracker specific for Release 1.7 Quality Check, and any other appropriated tool.
- when ? 2003-07-12
- who ? mose
2/ Release Candidate branching
A branch in CVS is constituted for the release candidate, so if a developer want to add new features for the 1.7.1 or the 1.8 he can stick on the main trunk. But all avalaible efforts are required for bugfix, when possible.
- what ?
merge SQL files tiki.sql and tiki-db1.6to1.7.sql
branch cvs :
Copy to clipboardcvs tag -b release_eta_carinea_rc1 - where ? on the CVS
- when ? 2003-07-12
- who ? mose
3/ Release candidate diffusion
Extraction from CVS of a package from RC branch, as if it was the release, and public diffusion.
- what ? make package :
Copy to clipboardcvs co -d tikiwiki_1.7rc1 -r release_eta_carinea_rc1 tiki find tikiwiki_1.7rc1 -name CVS -type d | xargs -- rm -rf find tikiwiki_1.7rc1 -name .cvsignore -type f | xargs -- rm -f # at that step, it's good to edit readme and changelog file and verify their information # concerning version number of the current package tar -czf tikiwiki_1.7rc1.tar.gz tikiwiki_1.7rc1 tar --bzip2 -cf tikiwiki_1.7rc1.tar.bz2 tikiwiki_1.7rc1 - where ? on a local computer, then upload on sourceforge, and announce on sourceforge, and tikiwiki.org
- when ? 2003-07-12
- who ? contributor capable of release on sourceforge, and one that has news admin rights, and a tikiwiki.org registered user
marclaporte: RC1 promo on SF and FM has been done. It would be nice to also have .zip file
4/ Release Candidate testing and fixing (including finishing translations)
Directly on the CVS main trunk, all bugfixes are applied on the RC branch (that will be merged to main trunk at release time). Go to 3/ until no bugs (ideally) or just a few (if times passes too long).
- what ?
The best solution for testing and fixing is to checkout a separate local version, or it's a mess. If applicable and possible, it's good to commit to both branches when it's a bugfix. If it's db structure fix double commit is mandatory. Note that starting with v1.8 we should adopt the DataBaseDevContrib rule that double each commit with the commit of a patch (wasn't commented yet, in need for feedack).
to get the Release Candidate from CVS
Copy to clipboardcvs co -d tikiwiki_1.7rc1 -r release_eta_carinea_rc1 tiki
to update an existing copy with Release Candidate
Copy to clipboardcd tikidir && cvs update -r release_eta_carinea_rc1
when your version is tagged, that tag gets sticky, so you can use cvs update and cvs commit without specifying the release tag. To get rid of that sticky tag, use the update flag -A
Copy to clipboardcvs update -A - where ? on the CVS, on mailing-list, on tikiwiki.org
- when ? 2003-07-12 to 2003-07-19 or more, or less
- who ? people able to fix a bug or translate a sentence and commit to CVS
5/ Evidence of the validity of a Release Candidate
When on the devel mailing-list there are enough of positive report about the stability of the release candidate, then Release is planned. It's an arbitrary decision that has to take in account that it's not good to stay in rc state too long, because merge bring more oddities when the branch separates too much from the trunk. Well, it's just comfort. If there is bugs, it's not releasable, that's what counts.
- what ? group decision
- where ? mailing-list, tikiwiki.org, irc channel
- when ? mid july til end july maybe
- who ? anyone
6/ Release Packaging
Tag of the final release_eta_carinea, then same steps as 4/ but, with release tag. Note that we will use a decompressed name of directory like tikiwiki_1.7 so we are compatible with gentoo update system (Lorinc plan).
- what ? package, and send to release channels
- where ? on a local computer, then upload on sourceforge, and announce on sourceforge, and tikiwiki.org
- when ? when applicable
- who ? same as for release candidate
7/ merging and branching
The branch release_eta_carinea should stay branched, as it will become the bugfix branch for an eventual 1.7.1 if it's required by circumstance (depends on number and severity level of bugs). The main trunk will be the 1.8 version, as we had recently a lot of new developers and they are planning to change (and ameliorate) many things. There will be probably another branching about an experimental database restructuration branch, because some homogeneity can be added, and it's a huge change. The 1.7 version is intended to be as stable as possible. all subsequent 1.7.x version will only be bugfixes, no added features. (hrum, I state that rather radically, please moderate me if I mistake).
8/ Public announce and release
That part is mostly under the coordination of marclaporte (to be written)