Re: [boost] New release procedure?
At 11:38 AM 3/6/2003, Beman Dawes wrote: >At 11:35 AM 3/5/2003, David Abrahams wrote: > > >>> The multiple merge thing is probably much less of an issue when > >>> working from trunk to branch, but it still could be useful to have > >>> the tag. I would call the tag "merged_to_". > >> > >> So this is something each developer would do when merging to > >> the branch from MAIN if they want 'extra' information > >> in CVS about where the merge took place? If this is > >> correct, I'm generally opposed to this extra step as > >> I don't see what it is going to buy you above and beyond > >> what you can get in CVS log command. Am I missing > >> something? > > > >If you make a big change on the trunk and need to merge to the > >branch, and then you do it again, you want > > > > cvs merge -jmerged_to_RC_whatever -jHEAD > > > >In order to make the merge work properly. If the release manager > >doesn't tag the head at the merge point, the first person to merge > >from trunk to branch messes up that arrangement. more/release_procedures.htm has been updated to reflect these discussions. The changes to more/release_procedures.htm were made on the main trunk, and then merged into RC_1_30_0, and the process repeated several times as the instructions were refined and corrected. In other words, the procedure was applied to its own documentation:-) At least in WinCVS, this was a good deal easier than the old way IMO. Please take a look at more/release_procedures.htm and suggest any corrections necessary. Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New release procedure?
At 11:35 AM 3/5/2003, David Abrahams wrote: >>> The multiple merge thing is probably much less of an issue when >>> working from trunk to branch, but it still could be useful to have >>> the tag. I would call the tag "merged_to_". >> >> So this is something each developer would do when merging to >> the branch from MAIN if they want 'extra' information >> in CVS about where the merge took place? If this is >> correct, I'm generally opposed to this extra step as >> I don't see what it is going to buy you above and beyond >> what you can get in CVS log command. Am I missing >> something? > >If you make a big change on the trunk and need to merge to the >branch, and then you do it again, you want > > cvs merge -jmerged_to_RC_whatever -jHEAD > >In order to make the merge work properly. If the release manager >doesn't tag the head at the merge point, the first person to merge >from trunk to branch messes up that arrangement. OK, I've added the tag "merged_to_RC_1_30_0" to the CVS at the appropriate point in time. It took a couple of hours experimenting with the sandbox to figure out how to do this correctly. WinCVS (and presumably cvs itself) seems to report time as UTC, but expects input times to be local. The tagging itself took over an hour even though SourceForge CVS seemed to running very quickly this morning on other operations. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New release procedure?
> >The multiple merge thing is probably much less of an issue when > >working from trunk to branch, but it still could be useful to have > >the tag. I would call the tag "merged_to_". > >OK, I'll add that to the procedure. > > >Does that clear up my concern? > >Yes, thanks. I'll aim to get the new tag and procedure page in place later >today. Just to be clear on my previous post, I'm asking for clarification on the benefits and need to complicate the procedure from it's current form. But please, if you see an advantage don't let my questions stop you from moving forward. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New release procedure?
"Jeff Garland" <[EMAIL PROTECTED]> writes: >> > What is the point of that? How are the tags used? >> >> The point is that if there are multiple merges from the trunk to the >> branch, you'll need something to mark the version on the trunk of the >> previous merge. At the point you first create the branch, the >> previous merge point is the same as the branch point. >> >> The multiple merge thing is probably much less of an issue when >> working from trunk to branch, but it still could be useful to have >> the tag. I would call the tag "merged_to_". > > So this is something each developer would do when merging to > the branch from MAIN if they want 'extra' information > in CVS about where the merge took place? If this is > correct, I'm generally opposed to this extra step as > I don't see what it is going to buy you above and beyond > what you can get in CVS log command. Am I missing > something? If you make a big change on the trunk and need to merge to the branch, and then you do it again, you want cvs merge -jmerged_to_RC_whatever -jHEAD In order to make the merge work properly. If the release manager doesn't tag the head at the merge point, the first person to merge from trunk to branch messes up that arrangement. -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] New release procedure?
> > What is the point of that? How are the tags used? > > The point is that if there are multiple merges from the trunk to the > branch, you'll need something to mark the version on the trunk of the > previous merge. At the point you first create the branch, the > previous merge point is the same as the branch point. > > The multiple merge thing is probably much less of an issue when > working from trunk to branch, but it still could be useful to have > the tag. I would call the tag "merged_to_". So this is something each developer would do when merging to the branch from MAIN if they want 'extra' information in CVS about where the merge took place? If this is correct, I'm generally opposed to this extra step as I don't see what it is going to buy you above and beyond what you can get in CVS log command. Am I missing something? Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New release procedure?
At 09:50 AM 3/5/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: > >... >> Dave, what did you mean by that? It sounds like you expect the >> RC_1_30_0 tag to go on the main trunk and some other tag on the >> branch. > >No. > >> What is the point of that? How are the tags used? > >The point is that if there are multiple merges from the trunk to the >branch, you'll need something to mark the version on the trunk of the >previous merge. At the point you first create the branch, the >previous merge point is the same as the branch point. Ah! That makes sense. >The multiple merge thing is probably much less of an issue when >working from trunk to branch, but it still could be useful to have >the tag. I would call the tag "merged_to_". OK, I'll add that to the procedure. >Does that clear up my concern? Yes, thanks. I'll aim to get the new tag and procedure page in place later today. --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] New release procedure?
Beman Dawes <[EMAIL PROTECTED]> writes: > At 09:53 AM 3/4/2003, Jeff Garland wrote: > > >Right, sorry for dropping this. As I recall I was hoping for > someone more > >expert with WinCVS and some of the other tools to fill in the details > >of how to make changes. > >... The basic CVS procedure for developers looks like it is in > >place. I don't think the WinCVS procedure was updated. > > OK, I'll commit your changes and then add my interpretation of how it > would work on WinCVS. But I need to get answers from Dave first. See > below. > > >> I'd really like it to include the Release Procedures for the Release > >> Manager, which is currently blank. While I understand the general > idea, >> I'm > >> not sure what the release manager does differently. How is the branch > >> named? What is the tag that goes on the main trunk and how is it named? > > > >There never have been procedures for the release manager, but they would > >be basically the same as today. I would expect we would name branches > >exactly as we do now. There may be some detail about how the > >branch has to be created, but other than that it would be the same. > > What is confusing me is Dave Abrahams' comment of a day or so ago: > > >Didn't we agree that we were going to tag the trunk and generally do > >any merges from the trunk to the branch? This tag appears to be on > >the branch AFAICT. > > Dave, what did you mean by that? It sounds like you expect the > RC_1_30_0 tag to go on the main trunk and some other tag on the > branch. No. > What is the point of that? How are the tags used? The point is that if there are multiple merges from the trunk to the branch, you'll need something to mark the version on the trunk of the previous merge. At the point you first create the branch, the previous merge point is the same as the branch point. The multiple merge thing is probably much less of an issue when working from trunk to branch, but it still could be useful to have the tag. I would call the tag "merged_to_". Does that clear up my concern? -- Dave Abrahams Boost Consulting www.boost-consulting.com ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] New release procedure? [was: 1.30.0 branch-for-release complete]
At 09:53 AM 3/4/2003, Jeff Garland wrote: >Right, sorry for dropping this. As I recall I was hoping for someone more >expert with WinCVS and some of the other tools to fill in the details >of how to make changes. >... The basic CVS procedure for developers looks like it is in >place. I don't think the WinCVS procedure was updated. OK, I'll commit your changes and then add my interpretation of how it would work on WinCVS. But I need to get answers from Dave first. See below. >> I'd really like it to include the Release Procedures for the Release >> Manager, which is currently blank. While I understand the general idea, >> I'm >> not sure what the release manager does differently. How is the branch >> named? What is the tag that goes on the main trunk and how is it named? > >There never have been procedures for the release manager, but they would >be basically the same as today. I would expect we would name branches >exactly as we do now. There may be some detail about how the >branch has to be created, but other than that it would be the same. What is confusing me is Dave Abrahams' comment of a day or so ago: >Didn't we agree that we were going to tag the trunk and generally do >any merges from the trunk to the branch? This tag appears to be on >the branch AFAICT. Dave, what did you mean by that? It sounds like you expect the RC_1_30_0 tag to go on the main trunk and some other tag on the branch. What is the point of that? How are the tags used? --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
RE: [boost] New release procedure? [was: 1.30.0 branch-for-releasecomplete]
> No one disagreed with this assessment. > > Jeff Garland posts a partially updated set of developer procedures: > http://aspn.activestate.com/ASPN/Mail/Message/1411802/release_procedures.htm > > At this point the discussion fragments into details and corner cases. The > updated release_procedures.htm was never committed to CVS. Right, sorry for dropping this. As I recall I was hoping for someone more expert with WinCVS and some of the other tools to fill in the details of how to make changes. > So, if we are going to do merges from the trunk to the branch for 1.30.0 we > need a finalized procedure right away. Jeff? Dave? That's true. The basic CVS procedure for developers looks like it is in place. I don't think the WinCVS procedure was updated. > I'd really like it to include the Release Procedures for the Release > Manager, which is currently blank. While I understand the general idea, I'm > not sure what the release manager does differently. How is the branch > named? What is the tag that goes on the main trunk and how is it named? There never have been procedures for the release manager, but they would be basically the same as today. I would expect we would name branches exactly as we do now. There may be some detail about how the branch has to be created, but other than that it would be the same. Jeff ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] New release procedure? [was: 1.30.0 branch-for-release complete]
At 06:45 PM 3/1/2003, David Abrahams wrote: >Beman Dawes <[EMAIL PROTECTED]> writes: > >> The tag is RC_1_30_0 > >Didn't we agree that we were going to tag the trunk and generally do >any merges from the trunk to the branch? This tag appears to be on >the branch AFAICT. OK, I've now gone back and read the entire thread. Here is a summary: "Jeff Garland" <[EMAIL PROTECTED]> writes: > It seems to me that part of the release process that would delay merges > from the candidate branch to the main branch is misguided. Critical > changes made to the release branch should be immediately merged on the > main branch. This avoids the issues of forgetting to merge later > which can lead to lost fixes or fixes that are much harder to merge. At 05:46 PM 10/24/2002, David Abrahams wrote: >I think the whole approach of merging from the release to the main >trunk is totally misguided. If there's a fix which _can_ be applied in >the trunk, it should be made there *first*. At least if it breaks >something in the release candidate we'll be more likely to hear about >it that way. If the trunk has already diverged too far for the fix to >be applicable, it's a non-issue anyway. No one disagreed with this assessment. Jeff Garland posts a partially updated set of developer procedures: http://aspn.activestate.com/ASPN/Mail/Message/1411802/release_procedures.htm At this point the discussion fragments into details and corner cases. The updated release_procedures.htm was never committed to CVS. So, if we are going to do merges from the trunk to the branch for 1.30.0 we need a finalized procedure right away. Jeff? Dave? I'd really like it to include the Release Procedures for the Release Manager, which is currently blank. While I understand the general idea, I'm not sure what the release manager does differently. How is the branch named? What is the tag that goes on the main trunk and how is it named? Thanks, --Beman ___ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
