>I would like to do a longer release candidate. Rather than actually doing a release, we will do the announcements[snip]
I'm not talking about your 1.0 release candidates, for now it will remain with the Alpha release series. We can give our series a new name, perhaps go with "Gamma" or "Upsilon" or maybe even "Zeta" or another greek character in order to move into a
0.9.x release stage, but not into 1.0 releases.
Those being
* scons needs to have "scons install" and the files in a folder in the
tar (not on the tar root) before releasing. Dont worry about the other
things. Those two are important and should be done before anything else.
* old maps with old map header need to be ignored in all situations that would cause a crash, freeze, or any other problems (like custom games being the main one, followed by load game and map editor).
All the maps that I have access to (the original maps that my system downloads) are all ignored properly, so I don't know what you are talking about.
Also, we probably don't need a branch for the RC, rather, branch of any new work. Example, between RC1 and RC2, there will be bug fixes and a few new features. those new features should be in a branch (like normal) while bug fixed remain in master. That way, we can tell people the RC is on master, so that when they go to get it, any bugs reported and fixed wont show up for them (so we wont get duplicate reports!).
A branch for the release candidate is quite critical to allow for other work to continue, but to maintain the release-candidates feature freeze.
It makes more sense to me to have master as the bug fixed RC branch :P
Then we wouldn't easily be able to do a feature freeze on this longer RC.
>I will be prepared to do the release candidate within a couple of days, after I clear up all known bugs.
Sounds good. Be sure to do those two things listed above ;)
Regards
Kieran
_______________________________________________
glob2-devel mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/glob2-devel