Philippe Bossut wrote: > - S1: commit on the 0.7 Preview branch: > - Pros: simple topology, allow big change in trunk immediately, we > already know 0.7.1 will need all bug fixes plus those already targeted > - Cons: goes against C1 (we may destabilize the branch preventing a > quick fix to be released)
This isn't much of a con actually. We can easily create 0.7.0.x branch from the 0.7 release tag without disrupting any other branches (like 0.7.1). > - S2: commit on the trunk: > - Pros: simple topology, keep everyone focused on the immediate short > term objective, no change required on TBox, build, etc... to get 0.7.1 out > - Cons: prevent big rework to be done (people will need to create > private branches) I prefer S2. Looking at 0.7.1 bugs, most developers actually have some bugs in that milestone. Those that don't/won't have any 0.7.1 work can work on a branch until we open the trunk for 0.8. Keeping 0.7.1 on trunk (at least for a while) also means that it gets the most testing, and we don't need to do anything special about Tinderboxes. The plan is also to do a quick 0.7.1 (like a month of work), so it shouldn't impact 0.8 much. I'd still leave open the option of branching 0.7.1 a little later, say when we get to 15 code bugs. At that point we'd then probably want some Tinderbox support for that branch as well, which would mean that Tinderbox cycle times would increase while the branch Tboxes were operational. All in all, in my opinion S2 would mean the least disruption for most people. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
