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).
Public announce that The release is now started and can take some days. CVS is under pressure.
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.
cvs tag -b release_eta_carinea_rc1
Extraction from CVS of a package from RC branch, as if it was the release, and public diffusion.
cvs 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
marclaporte: RC1 promo on SF and FM has been done. It would be nice to also have .zip file
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).
cvs co -d tikiwiki_1.7rc1 -r release_eta_carinea_rc1 tiki
cd tikidir && cvs update -r release_eta_carinea_rc1
cvs update -A
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.
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).
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).
That part is mostly under the coordination of marclaporte (to be written)
1) |
17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting |
2) |
21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting |
3) |
19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting |
4) |
Tiki birthday |