On Aug 21, 2007, at 2:16 AM, Philippe Bossut wrote:
So, what do we do? Here's a plan:- Chandler Desktop declares ZBR and branches as soon as the 4 "non index" bugs here above are fixed (hopefully this week) - We cut an RC and move ahead with the QA process (help from everyone in going through the test plan will certainly be required) - We release a Desktop 0.7.0 so that users can start using the Cosmo 0.7 upgraded hub with a version that matches - We continue to test, fix, etc... the upcoming index issues (and others recall class bugs if any) and follow up with an update *very soon* after, without waiting for all the other 0.7.1 things to come in (i18n, script recording, interop).Mitigation elements:-> we need to put in release notes high up that we're aware of such issues -> we need to document and promote the use of export/reload (aka dump/reload) in said release notes so that users have a safe path while we work out those remaining index issuesI'm sure there's comments on such a plan so I'd be glad to hear them.
I wanted to comment on the version numbering conversation you mentioned above and also I heard in the desktop meeting today.
From a build/release point of view, and also from a best-practices standpoint, the method to use is this:
- when ZBR is hit, branch trunk to 0.7.0 and start the 0.7.0-RC cycle
- make trunk 0.7.1
- any changes required to 0.7.0 branch due to bugs are patched and
0.7.0.# is released
--- Bear Build and Release Engineer Open Source Applications Foundation (OSAF) [EMAIL PROTECTED] http://www.osafoundation.org [EMAIL PROTECTED] http://code-bear.com PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
PGP.sig
Description: This is a digitally signed message part
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
