Re: integration and master divergence
Maik Musall <[email protected]>
| Newsgroups | gmane.comp.web.webobjects.wonder-disc |
|---|---|
| Message-ID | <[email protected]> |
Hi Chuck, Am 18.07.2012 um 22:19 schrieb Chuck Hill: >> So, IMHO, we can keep everyone happy by continuing with two branches (just labels on commits) and someone (anyone with commit access) can periodically make a release candidate branch based on master, integrate one-month+ old integration, push it and announce the release candidate via pull request of it to master. > > What about the case where that point in time had a bug that was fixed in a later commit, perhaps the next week? Merging a point in time does not guarantee a working version, just that any bugs in that merge were fixed in a subsequent commit. Addressing that seems to lead us back to cherry picking the commit. What am I missing? Well, the whole point of the release candidate is being able to test it, which only makes sense if found bugs are fixed before it becomes master. Now those fixes can either be new, in which case the fix commit would get applied to both rc and integration, or it exists already in integration as a later commit, in which case it is pushed to rc. You can call the latter cherry picking, but it sounds reasonable and natural to me... Maik ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/