Re: [vote] 2.0.1/2.1 dev process

Alan D. Cabrera wrote: > Brett Porter wrote, On 11/24/2005 4:23 PM: > >> My thoughts: >> - this is more risky that it will be missed if someone misses one >> >> > This is not as likely if the commits are made to both lines at the same > time. I don't understand this reasoning. If using this te

Re: [vote] 2.0.1/2.1 dev process

Brett Porter wrote, On 11/24/2005 4:23 PM: My thoughts: - this is more risky that it will be missed if someone misses one This is not as likely if the commits are made to both lines at the same time. Also, there will be times when it will not make sense to apply the branch change in the tr

Re: [vote] 2.0.1/2.1 dev process

My thoughts: - this is more risky that it will be missed if someone misses one - its more cumbersome on an individual commit - the merge is not just the patch authors knowledge, but also the trunk changers knowledge, so its not always that simple if there is a clash so it might require some discuss

Re: [vote] 2.0.1/2.1 dev process

I agree that they should be done no less than once per week. About RCs I think we should tag them as that and add the 2.1 tag when the RC is accepted. We shoudn't remove the RC tags because we may want to reproduce the build for any reason. I'm fine with the other stuff On 11/24/05, Alan D. Cabr

Re: [vote] 2.0.1/2.1 dev process

Brett Porter wrote, On 11/22/2005 9:07 PM: - use of the flying fish technique (ie bugfix only release goes over to /branches/2.0.x) * we should merge at each point release (2.0.1, 2.0.2) back to trunk * can do interim merges if there are long time lines on those releases It has always

Re: build labelling was: [vote] 2.0.1/2.1 dev process

Jason van Zyl wrote: Brett Porter wrote: - RC's are the actual build. It will report version "2.0", and is differentiated from the actual final release (if different), by the build timestamp. If the RC is not suitable for any reason, we remove the old tag, and redo the release Can you expan

Re: [vote] 2.0.1/2.1 dev process

Brett Porter wrote: - RC's are the actual build. It will report version "2.0", and is differentiated from the actual final release (if different), by the build timestamp. If the RC is not suitable for any reason, we remove the old tag, and redo the release Can you expand on this and possibly

[vote] 2.0.1/2.1 dev process

This thread never really got rounded up, so I thought I'd summarise some points we seemed to be in agreeance on. Please vote +1 for all, or +1/+0/-1 for every item. - use of the flying fish technique (ie bugfix only release goes over to /branches/2.0.x) * we should merge at each point relea