On 11/12/09 11:17 AM, John Plevyak wrote: > > And then you have a short feature lock when trunk goes RTC before it > becomes the new stable. Everyone wants that to be short because it > is a pain so they try to ensure trunk is stable. That is like the 6 > month + feature lock window that the OpenBSD team uses. They also > make the feature lock date a surprise to encourage early checkin.
Right ... when there's a lot of commiter activity, that "feature freeze" period where things become RTC (anyway) can become really protracted. Admitting that this is a reality, why not just operate in RTC always which lets you push out releases "on demand" - or, discourage commits to trunk/HEAD and instead have developers commit to their own personal branch which lets developers share changes and use the VCS, but ensures that trunk/HEAD from which releases are branched stays stable and reliable as changes only get merged from branches to trunk after review. -- Dossy Shiobara | [email protected] | http://dossy.org/ Panoptic Computer Network | http://panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
