On 09/13, Daryl C. W. O'Shea wrote: > Perhaps I'm not following what has been said here. I thought it was > being suggested we use trunk "forever" as the 3.4 development tree, > rather than branching it at some point.
Yes, that is the preference expressed by me, Axb, and Kevin. Daryl and Mark have objected. I think that's the opinions that have been expressed? On 09/14, Mark Martinec wrote: > To me it makes most sense to create a 3.4 branch at the time of a release > or shortly before it. So I'm closer to Kevin on this than with Daryl. Why? What would we then do for the release scheduled for January? Branch it again and call it 3.5? I guess I wouldn't really mind if people wanted to do a branch per release. Branch trunk to 3.4.0 for this release, branch trunk to 3.4.1 in January. Does anybody object to that idea? The concern here is primarily people throwing non-reviewed commits into trunk just before a release off of trunk, right? The reason that doesn't concern me is, I'd like to: 1) Put out a release candidate. 2) Whenever a bug is found that makes it not qualify for a global release, fix the bug and put out another release. 3) After a month of a few people actively running the latest release candidate without needing a new release, call it a stable / global release. Because I think testing in a live environment is better than multiple reviews of every commit. From a quality perspective, and especially from an overhead perspective. -- "theres a lot more to life than chicks none of it matters but theres a lot of it" - LeRoy, #motorcycles, #EFNet, 7/18/06 http://www.ChaosReigns.com
