Updated Development and Release Practices for 1.35.0
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users. I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0. Comments appreciated. --Beman
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
Is there a rationale for the release structure, and specifically of the location of the tags: svn/boost/ release/ next/ (boost-root) RC_1_35_0_n/ (boost-root) 1_35_0/ (boost-root) Instead of: svn/boost/ release/ (boost-root) tags/ RC_1_35_0_n/ (boost-root) 1_35_0/ (boost-root) ?? If the reason is to make the permissions easier to manage. Did you consider a more traditional svn structure of: svn/boost/release/ trunk/ (boost-root) tags/ RC_1_35_0_n/ (boost-root) 1_35_0/ (boost-root) ?? -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
Is there a rationale for the release structure, and specifically of the location of the tags:
svn/boost/ release/ next/ (boost-root) RC_1_35_0_n/ (boost-root) 1_35_0/ (boost-root)
Instead of:
svn/boost/ release/ (boost-root) tags/ RC_1_35_0_n/ (boost-root) 1_35_0/ (boost-root)
I considered svn/boost/release/(boost-root) but was afraid it would be confused with the most recent release, since there is nothing to identify it as anything else.
??
If the reason is to make the permissions easier to manage.
That's one part of the rationale. I also wanted a focal point for casual browers to find release related trees.
Did you consider a more traditional svn structure of:
svn/boost/release/ trunk/ (boost-root) tags/ RC_1_35_0_n/ (boost-root) 1_35_0/ (boost-root)
No, that approach didn't occur to me. I think I like it slightly better than my proposal. Anyone else have an opinion on this? --Beman
Beman Dawes wrote:
Rene Rivera wrote:
Did you consider a more traditional svn structure of:
svn/boost/release/ trunk/ (boost-root) tags/ RC_1_35_0_n/ (boost-root) 1_35_0/ (boost-root)
No, that approach didn't occur to me. I think I like it slightly better than my proposal.
Anyone else have an opinion on this?
I'm not a boost library author yet, but as a user, I like the traditional svn structure. Of course, that is what I am used to but I suspect most users of subversion are following a scheme that is close to the recommended practices. -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
Beman Dawes <bdawes <at> acm.org> writes: [...]
Did you consider a more traditional svn structure of:
svn/boost/release/ trunk/ (boost-root) tags/ RC_1_35_0_n/ (boost-root) 1_35_0/ (boost-root)
No, that approach didn't occur to me. I think I like it slightly better than my proposal.
Anyone else have an opinion on this?
I take it that svn/boost/release/trunk would correspond to 'next' in your document. In this case I'm all for this setup. Cheers, Nicola Musatti
Wouldn't generally accepted SVN setup be: svd/boost /trunk (same as current trunk) /tags RC_1_35_1... (snapshot when tarball is created) /branches RC_1_35 (next release in being updated) joe_shmoes_library_development .... Robert Ramey Nicola Musatti wrote:
Beman Dawes <bdawes <at> acm.org> writes: [...]
Did you consider a more traditional svn structure of:
svn/boost/release/ trunk/ (boost-root) tags/ RC_1_35_0_n/ (boost-root) 1_35_0/ (boost-root)
No, that approach didn't occur to me. I think I like it slightly better than my proposal.
Anyone else have an opinion on this?
I take it that svn/boost/release/trunk would correspond to 'next' in your document. In this case I'm all for this setup.
Cheers, Nicola Musatti
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
on Thu Aug 23 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Wouldn't generally accepted SVN setup be:
svd/boost /trunk (same as current trunk) /tags RC_1_35_1... (snapshot when tarball is created) /branches RC_1_35 (next release in being updated) joe_shmoes_library_development ....
Yes, that would be usual, and it's roughly what I was going to suggest (the tag RC_1_35_1 should be something like 1_35_1a1, because we may end up releasing multiple release candidates for a given Boost version). Is there a good reason not to follow it? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Thu Aug 23 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Wouldn't generally accepted SVN setup be:
svd/boost /trunk (same as current trunk) /tags RC_1_35_1... (snapshot when tarball is created) /branches RC_1_35 (next release in being updated) joe_shmoes_library_development ....
Yes, that would be usual, and it's roughly what I was going to suggest (the tag RC_1_35_1 should be something like 1_35_1a1, because we may end up releasing multiple release candidates for a given Boost version). Is there a good reason not to follow it?
This is why I asked for a rationale ;-) The two reasons Beman gave (one of which I guessed): * To make the permissions easier to manage. (my words) * Focal point for casual browsers to find release related trees. (Beman's words) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Thu Aug 23 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
on Thu Aug 23 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Wouldn't generally accepted SVN setup be:
svd/boost /trunk (same as current trunk) /tags RC_1_35_1... (snapshot when tarball is created) /branches RC_1_35 (next release in being updated) joe_shmoes_library_development ....
Yes, that would be usual, and it's roughly what I was going to suggest (the tag RC_1_35_1 should be something like 1_35_1a1, because we may end up releasing multiple release candidates for a given Boost version). Is there a good reason not to follow it?
This is why I asked for a rationale ;-) The two reasons Beman gave (one of which I guessed):
* To make the permissions easier to manage. (my words) * Focal point for casual browsers to find release related trees. (Beman's words)
svn/boost/ trunk/ tags/ ... release/ 1_34_1 1_35_0 ... branches/ release/ 1_35_0 ... libraries/ python/ serialization/ ? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
svn/boost/
trunk/
tags/ ... release/ 1_34_1 1_35_0 ... branches/ release/ 1_35_0 ... libraries/ python/ serialization/
?
What's wrong with using a "non-sanctioned" structure? Must we insist on trunk/tags/branches? Beman's original release/ next - RC_x - x wasn't bad.
on Thu Aug 23 2007, "Peter Dimov" <pdimov-AT-pdimov.com> wrote:
David Abrahams wrote:
svn/boost/
trunk/
tags/ ... release/ 1_34_1 1_35_0 ... branches/ release/ 1_35_0 ... libraries/ python/ serialization/
?
What's wrong with using a "non-sanctioned" structure? Must we insist on trunk/tags/branches?
No, but doing something reminiscent of the usual structure will be easier to grasp for most people. It's not a big deal, but Beman's original proposal used essentially the same rationale to justify some of its choices. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Thu Aug 23 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
on Thu Aug 23 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
Wouldn't generally accepted SVN setup be:
svd/boost /trunk (same as current trunk) /tags RC_1_35_1... (snapshot when tarball is created) /branches RC_1_35 (next release in being updated) joe_shmoes_library_development .... Yes, that would be usual, and it's roughly what I was going to suggest (the tag RC_1_35_1 should be something like 1_35_1a1, because we may end up releasing multiple release candidates for a given Boost version). Is there a good reason not to follow it? This is why I asked for a rationale ;-) The two reasons Beman gave (one of which I guessed):
* To make the permissions easier to manage. (my words) * Focal point for casual browsers to find release related trees. (Beman's words)
svn/boost/
trunk/
tags/ ... release/ 1_34_1 1_35_0 ... branches/ release/ 1_35_0 ... libraries/ python/ serialization/
That would work, and avoid having two directories named trunk. OTOH it now has two directories named 1_35_0. Is there any point having two copies of the final for a release? Wouldn't it be potentially less confusing for the release manager to move 1_35_0 from svn/boost/branches/release to svn/boost/release at the time of release? And since there would only be one release work-in-progress directory at a time under branches/release, the release level could be eliminated. So after 1.35.0 ships, the tree would look like: svn/boost/ trunk/ tags/ ... release/ ... 1_34_1 1_35_0 branches/ 1_36_0 libraries/ python/ serialization/ --Beman
Beman Dawes wrote:
That would work, and avoid having two directories named trunk. OTOH it now has two directories named 1_35_0.
Is there any point having two copies of the final for a release? Wouldn't it be potentially less confusing for the release manager to move 1_35_0 from svn/boost/branches/release to svn/boost/release at the time of release? And since there would only be one release work-in-progress directory at a time under branches/release, the release level could be eliminated.
So after 1.35.0 ships, the tree would look like:
svn/boost/
trunk/
tags/ ... release/ ... 1_34_1 1_35_0 branches/ 1_36_0 libraries/ python/ serialization/
Yep, we don't need copies of release-candidates lying around: once these become official releases, they can be moved to the /release/ directory. Merrily painting that bike shed yours, John.
on Thu Aug 23 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Wouldn't it be potentially less confusing for the release manager to move 1_35_0 from svn/boost/branches/release to svn/boost/release at the time of release? And since there would only be one release work-in-progress directory at a time under branches/release, the release level could be eliminated.
So after 1.35.0 ships, the tree would look like:
svn/boost/
trunk/
tags/ ... release/ ... 1_34_1 1_35_0 branches/ 1_36_0 libraries/ python/ serialization/
Sounds good to me. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Thu Aug 23 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Wouldn't it be potentially less confusing for the release manager to move 1_35_0 from svn/boost/branches/release to svn/boost/release at the time of release? And since there would only be one release work-in-progress directory at a time under branches/release, the release level could be eliminated.
So after 1.35.0 ships, the tree would look like:
svn/boost/
trunk/
tags/ ... release/ ... 1_34_1 1_35_0 branches/ 1_36_0 libraries/ python/ serialization/
Sounds good to me.
This sound good to me as well. I do have a couple of observations To me - the "release" in tags/release is redundant so it could just as well be tags/ 1_34_1 1_35_0 .... The branches is fine as well. BUT it requires some explanation for users. I've been only recently learning how to use SVN to good advantage. I've been practicing on my own machine with my non-boost projects. a) Using the SVN interface with windows is veeerrrryyy slick. But like all slick stuff its not quite as easy as it first appears so when you want to do something you haven't done before you can get it wrong the first time. In my case, I made a branch of the whole RC_1_34_0 as it looked like making a branch of just one library would result in an SVN "branch" structure which didn't map exactly to the directory structure. Since SVN uses "cheap copy" this didn't have any big impact but now I see that it would have been simpler to do it differently. So a short explanation of how developers should do this would be helpful. I think that this has been covered in the emails but a short "SVN usage recommendations" would be helpful. Also I think following the common SVN pattern is a good idea if possible. b) I'm thinking that the tagged versions should be locked to prevent someone from accidently checking in any changes to them. Again I made such a blunder in the past. I think this is easy to do with SVN Robert Ramey
on Thu Aug 23 2007, "Robert Ramey" <ramey-AT-rrsd.com> wrote:
David Abrahams wrote:
on Thu Aug 23 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
Wouldn't it be potentially less confusing for the release manager to move 1_35_0 from svn/boost/branches/release to svn/boost/release at the time of release? And since there would only be one release work-in-progress directory at a time under branches/release, the release level could be eliminated.
So after 1.35.0 ships, the tree would look like:
svn/boost/
trunk/
tags/ ... release/ ... 1_34_1 1_35_0 branches/ 1_36_0 libraries/ python/ serialization/
Sounds good to me.
This sound good to me as well. I do have a couple of observations
To me - the "release" in tags/release is redundant
What if I want to create a tag unrelated to any release? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
So after 1.35.0 ships, the tree would look like:
svn/boost/
trunk/
tags/ ... release/ ... 1_34_1 1_35_0 branches/ 1_36_0 libraries/ python/ serialization/
Sounds good to me.
This sound good to me as well. I do have a couple of observations
To me - the "release" in tags/release is redundant
What if I want to create a tag unrelated to any release?
Like what? Truth is, it didn't occur to me that there would be any reason to create tag other than for a release. Robert Ramey
Robert Ramey wrote:
David Abrahams wrote:
To me - the "release" in tags/release is redundant
What if I want to create a tag unrelated to any release?
Like what? Truth is, it didn't occur to me that there would be any reason to create tag other than for a release.
Boost.Jam for example <http://svn.boost.org/trac/boost/browser/tags/jam>, or Boost.Build, or just about anything that is released on a different schedule than the Boost releases. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Robert Ramey wrote:
David Abrahams wrote:
To me - the "release" in tags/release is redundant
What if I want to create a tag unrelated to any release?
Like what? Truth is, it didn't occur to me that there would be any reason to create tag other than for a release.
Boost.Jam for example <http://svn.boost.org/trac/boost/browser/tags/jam>, or Boost.Build, or just about anything that is released on a different schedule than the Boost releases.
Ahhh - that's another one of my complaints. I would like to see these things on the same "schedule" and release procedure as any other component. That is it would be subject to the same release procedure and be changed only as part of a release. These things do have their own tests. The only think they are in directories other than "libs" but everything else applies. Robert Ramey
on Thu Aug 23 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Robert Ramey wrote:
David Abrahams wrote:
To me - the "release" in tags/release is redundant
What if I want to create a tag unrelated to any release?
Like what? Truth is, it didn't occur to me that there would be any reason to create tag other than for a release.
Boost.Jam for example <http://svn.boost.org/trac/boost/browser/tags/jam>, or Boost.Build, or just about anything that is released on a different schedule than the Boost releases.
Or just to mark some significant point in my library's development history. That's what tags are for. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Thu Aug 23 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Robert Ramey wrote:
David Abrahams wrote:
To me - the "release" in tags/release is redundant What if I want to create a tag unrelated to any release? Like what? Truth is, it didn't occur to me that there would be any reason to create tag other than for a release. Boost.Jam for example <http://svn.boost.org/trac/boost/browser/tags/jam>, or Boost.Build, or just about anything that is released on a different schedule than the Boost releases.
Or just to mark some significant point in my library's development history. That's what tags are for.
Perhaps mirror the branches organization scheme? tags/ ... release/ ... 1_34_1 1_35_0 libs/ ... python/ rev_2 ... serialization/ before_code_refactoring ... branches/ release libs/ ... python serialization ... --Beman
On 8/23/07, Beman Dawes <bdawes@acm.org> wrote:
[snip]
tags/ ... release/ ... 1_34_1 1_35_0 libs/ ... python/ rev_2 ... serialization/ before_code_refactoring ...
branches/ release libs/ ... python serialization ...
I have a question about the boost organization scheme. Does each project has a include directory with its own headers, instead of just one include directory where everything is mixed ? I really find it useful for each project to have its own include directory, specially when using boost.build where you can add include directories automatically with usage-requirements. I also find it useful to have another directory for headers that are only used for the libraries .cpp files. I usually call it headers or impl_include, the latter seem less confusing.
--Beman
Best regards, -- Felipe Magno de Almeida
Beman Dawes wrote:
So after 1.35.0 ships, the tree would look like:
svn/boost/
trunk/
tags/ ... release/ ... 1_34_1 1_35_0 branches/ 1_36_0 libraries/ python/ serialization/
Even though I prefer such top-down arrangements, that makes testing a bit harder. On each release we would need to update scripts and/or procedures to start testing 'svn/boost/branches/1_36_0' instead of 'svn/boost/branches/1_35_0'. Much easier would be to have 'svn/boost/branches/release'. The advantages: * Only one command for the release manager, an "svn copy" from "svn/branches/release" to "svn/tags/release/1_35_0". * No change to testing, and hence no interruption of testing. I don't see the problem with having multiple subdir with the same name, after all that's the point of such hierarchical namespace organization. Note, I'm only trying to find an arrangement that we can work with almost immediately per Beman's goal of getting a new release procedure going with minimal effort. We can always change it if we find it's less than ideal. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Beman Dawes wrote:
So after 1.35.0 ships, the tree would look like:
svn/boost/
trunk/
tags/ ... release/ ... 1_34_1 1_35_0 branches/ 1_36_0 libraries/ python/ serialization/
Even though I prefer such top-down arrangements, that makes testing a bit harder. On each release we would need to update scripts and/or procedures to start testing 'svn/boost/branches/1_36_0' instead of 'svn/boost/branches/1_35_0'. Much easier would be to have 'svn/boost/branches/release'. The advantages:
* Only one command for the release manager, an "svn copy" from "svn/branches/release" to "svn/tags/release/1_35_0".
* No change to testing, and hence no interruption of testing.
I don't see the problem with having multiple subdir with the same name, after all that's the point of such hierarchical namespace organization. Note, I'm only trying to find an arrangement that we can work with almost immediately per Beman's goal of getting a new release procedure going with minimal effort. We can always change it if we find it's less than ideal.
Argh... I completely forgot we were trying to keep the same name. But as you point out, we can use the branches/release name but otherwise leave the above scheme unchanged. OK... I've updated the trac page at http://svn.boost.org/trac/boost/wiki/ImprovingPractices I think we've now figured out where to put the bike shed for the 1.35.0 release. Let's move on to finalizing the rest of the 1.35.0 decisions. --Beman
on Thu Aug 23 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
OK... I've updated the trac page at http://svn.boost.org/trac/boost/wiki/ImprovingPractices
I think we've now figured out where to put the bike shed for the 1.35.0 release. Let's move on to finalizing the rest of the 1.35.0 decisions.
Sorry, I want to add an "s" //svn.boost.org/svn/boost/ trunk tags/ ... releases/ here-----------------------------^ ... 1_34_1 1_35_0 branches/ release libs/ ... python serialization ... So that we don't have two "release" directories without congruent structure. OK? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Thu Aug 23 2007, Beman Dawes <bdawes-AT-acm.org> wrote:
OK... I've updated the trac page at http://svn.boost.org/trac/boost/wiki/ImprovingPractices
I think we've now figured out where to put the bike shed for the 1.35.0 release. Let's move on to finalizing the rest of the 1.35.0 decisions.
Sorry, I want to add an "s"
//svn.boost.org/svn/boost/
trunk
tags/ ... releases/ here-----------------------------^ ... 1_34_1 1_35_0
branches/ release libs/ ... python serialization ...
So that we don't have two "release" directories without congruent structure. OK?
I think so, although I'm getting sleepy enough not to trust my judgment until morning. Let's see if anyone else objects, too. Also, be sure to read my reply to a posting of yours regarding tags for purposes other than releases, and let me know if you are OK with that resolution. --Beman
on Wed Aug 22 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
If the reason is to make the permissions easier to manage. Did you consider a more traditional svn structure of:
svn/boost/release/ trunk/ (boost-root) tags/ RC_1_35_0_n/ (boost-root) 1_35_0/ (boost-root)
??
I don't understand what trunk/ is doing under release/ The trunk itself will only rarely be the same as something we release, right? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Wed Aug 22 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
If the reason is to make the permissions easier to manage. Did you consider a more traditional svn structure of:
svn/boost/release/ trunk/ (boost-root) tags/ RC_1_35_0_n/ (boost-root) 1_35_0/ (boost-root)
??
I don't understand what trunk/ is doing under release/ The trunk itself will only rarely be the same as something we release, right?
Under Rene's scheme there are two trunk's - the development trunk and the release trunk. Several people commented that they liked the tradition "trunk" name rather than the "next" name I proposed. I agreed with them, as I was finding the "next" name awkward. Do you have a name you would find less confusing? --Beman
Beman Dawes wrote:
Under Rene's scheme there are two trunk's - the development trunk and the release trunk. Several people commented that they liked the tradition "trunk" name rather than the "next" name I proposed. I agreed with them, as I was finding the "next" name awkward.
Do you have a name you would find less confusing?
How about the old favorites "stable" and "development"; I like the idea of putting all releases (and candidates) under /release/ very much, but I too would find having two "trunk" directories rather confusing. John.
John Maddock wrote:
Beman Dawes wrote:
Under Rene's scheme there are two trunk's - the development trunk and the release trunk. Several people commented that they liked the tradition "trunk" name rather than the "next" name I proposed. I agreed with them, as I was finding the "next" name awkward.
Do you have a name you would find less confusing?
How about the old favorites "stable" and "development"; I like the idea of putting all releases (and candidates) under /release/ very much, but I too would find having two "trunk" directories rather confusing.
AFAICT some people seem to have problems realizing that "trunk" is orthogonal to "stable", "development", "release", etc. Some definitions as I see them: trunk Ongoing work of a product, projects, library, etc. tags Snapshots of previous work of a product, etc. branches Ongoing work which is intended for eventual merge to trunk. And the orthogonal part would be what a product is. Boost, being a collective work, has both "products" and "libraries". I see the Boost products as: stable/release The collection of accepted libraries, docs, and tools that are put out as releases as a single package. unstable/development The collection of accepted libraries, docs, and tools that are experimental or otherwise not ready for public use. sandbox Individual libraries that have not been accepted. HTH -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Hi! David Abrahams schrieb:
I don't understand what trunk/ is doing under release/ The trunk itself will only rarely be the same as something we release, right?
As I take it: The release/trunk will hold the steps of merging release-ready libraries. 1. people improve on /trunk/lib/XYZ 2. merge /trunk/lib/XYZ to /release/trunk/lib/XYZ 3. repeat step 2 for other libraries 4. when done tag /release/trunk as /release/tags/1_35_0 So before releasing the /release/trunk can be used to build the release candidate and improve it further. Frank
Frank Birbacher wrote:
Hi!
David Abrahams schrieb:
I don't understand what trunk/ is doing under release/ The trunk itself will only rarely be the same as something we release, right?
As I take it: The release/trunk will hold the steps of merging release-ready libraries.
1. people improve on /trunk/lib/XYZ 2. merge /trunk/lib/XYZ to /release/trunk/lib/XYZ 3. repeat step 2 for other libraries 4. when done tag /release/trunk as /release/tags/1_35_0
So before releasing the /release/trunk can be used to build the release candidate and improve it further.
Yep. We have changed the details of repository structure and directory names, but the basic process is as you describe it. Note that we can start the process of getting ready for the next release as soon as the last one is out the door. In terms of 1.35.0, that means we can start right away for any libraries that are ready to go. --Beman
I would emphasize a couple of missed steps: Beman Dawes wrote:
Frank Birbacher wrote:
Hi!
David Abrahams schrieb:
I don't understand what trunk/ is doing under release/ The trunk itself will only rarely be the same as something we release, right?
As I take it: The release/trunk will hold the steps of merging release-ready libraries.
1. people improve on /trunk/lib/XYZ 1.5 test library changes against the next release 2. merge /trunk/lib/XYZ to /release/trunk/lib/XYZ 3. repeat step 2 for other libraries 4. when done tag /release/trunk as /release/tags/1_35_0 5. retest the tarball
So before releasing the /release/trunk can be used to build the release candidate and improve it further.
There is no /release/trunk Building the trunk will result in something entirely diffferent than the next release. The only way the release can be improved is by merging in more code which has been separately tested. I'm not sure that wasn't over looked in the above. Robert Ramey
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
Suggestion for automated release testing criteria: * Release is tested continuously until there are no regressions for each release platform. * The continuous release testing is restarted when new changes are present from last regression free test point. I think those two simple rules cover all the testing use cases and is likely we can implement them either manually (through email exchanges), or automated (for example with Buildbot). One particular case of importance is that in the past some tests, irrespective of the quality of the test platform, fail intermittently. Hence testing continuously covers those situations. One issue that this brings up is in how we choose the release platforms. In the past it was an incremental choice. When the testing was clear for a platform and the test machine was reliable the release manager would deem the platform a release one. Is this approach still sufficient? And regardless, we should document this choice. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
Suggestion for automated release testing criteria:
* Release is tested continuously until there are no regressions for each release platform.
* The continuous release testing is restarted when new changes are present from last regression free test point.
I think those two simple rules cover all the testing use cases and is likely we can implement them either manually (through email exchanges), or automated (for example with Buildbot). One particular case of importance is that in the past some tests, irrespective of the quality of the test platform, fail intermittently. Hence testing continuously covers those situations.
You could provide an option in the regression.py script to check a web page to see what boost-roots currently needs testing. Some testers would prefer to always test against svn/boost/trunk, but other would be willing to activate the option, and test against the roots where we currently need testing. Sometimes that will just be the main trunk, but at other times the release trunk will also need testing, and if a breaking change is pending we may want to test some branch, too.
One issue that this brings up is in how we choose the release platforms. In the past it was an incremental choice. When the testing was clear for a platform and the test machine was reliable the release manager would deem the platform a release one. Is this approach still sufficient?
I'm going to suggest that we release on a quarterly basis. It may be easiest if the release manager, after consultation with the list, sets the release criteria compilers at the start of each release cycle, and doesn't normally change during the cycle.
And regardless, we should document this choice.
Yes, definitely. --Beman
Basically I think this is a big step in the right direction. I do think that one thing should be considered. The release manager has the responsability of generating a quality release. I think its only fair that he have the corresponding authority to restrict check-ins to the release to those packages that HE deems ready for release. That is, check-ins to the the ready-for-release branch would be subject to his prior approval. Or may he himself is the only authority - he would have a lock on the release branch. He might want to use this authority in a number of ways. a) he might be in the middle of making a release tarball and finishing up a couple of pending issues and not want anyone messing with the release while he does this. b) He might want to control that code is checked in to the the release one library at a time. This would be especially useful for pre-requiste libraries which might generate failures ni other libraries. By choosing to hold other check-ins in the meantime, he can be sure that any failures are due to interface breaking without having to start up a research project. Note that tool updates like bjam etc are in the same situation as pre-requisit libraries in that all libraries depend upon them. But my main point is still the first one. Its unfair and unrealistic to expect the release manager to create a good release unless he has the leverage and authority required to do that. Robert Ramey Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users.
I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0.
Comments appreciated.
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Basically I think this is a big step in the right direction.
I do think that one thing should be considered.
The release manager has the responsability of generating a quality release. I think its only fair that he have the corresponding authority to restrict check-ins to the release to those packages that HE deems ready for release. That is, check-ins to the the ready-for-release branch would be subject to his prior approval. Or may he himself is the only authority - he would have a lock on the release branch. He might want to use this authority in a number of ways.
a) he might be in the middle of making a release tarball and finishing up a couple of pending issues and not want anyone messing with the release while he does this.
b) He might want to control that code is checked in to the the release one library at a time. This would be especially useful for pre-requiste libraries which might generate failures ni other libraries. By choosing to hold other check-ins in the meantime, he can be sure that any failures are due to interface breaking without having to start up a research project. Note that tool updates like bjam etc are in the same situation as pre-requisit libraries in that all libraries depend upon them.
But my main point is still the first one. Its unfair and unrealistic to expect the release manager to create a good release unless he has the leverage and authority required to do that.
I agree with you 100%. Basically, everything under svn.boost.org/release is the domain of the release manager. I'll update the trac doc accordingly (but probably not until tomorrow) to reflect that. Thanks, --Beman
I continue to read, and re-read the document... I put in the macro to show an outline since the page is getting long ;-) Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
In the definitions there's the one for the prerequisite library <http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Prerequisitelibrary>. In reading that, and the places where it's mentioned, I think we can generalize that to "prerequisite component" to account for prerequisite tools. -- AFAIK most of the critical tools have accompanying tests now and hence we can put some guards against really bad things happening -- Or add a "prerequisite tool" concept and some procedure for how those are handled differently from "prerequisite libraries". -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Rene Rivera wrote:
I continue to read, and re-read the document... I put in the macro to show an outline since the page is getting long ;-)
Wow! That's really slick! Thanks! I had no idea such a feature was available.
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
In the definitions there's the one for the prerequisite library <http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Prerequisitelibrary>. In reading that, and the places where it's mentioned, I think we can generalize that to "prerequisite component" to account for prerequisite tools. -- AFAIK most of the critical tools have accompanying tests now and hence we can put some guards against really bad things happening -- Or add a "prerequisite tool" concept and some procedure for how those are handled differently from "prerequisite libraries".
For now, maybe just generalize to "prerequisite component". If you feel inclined, go ahead an make the change. Otherwise I'll do it tomorrow. I also want to expand the discussion of providing a stable development environment. We can do better than the current wording indicates. We will certainly want to continue updating the page as more comments come in and we refine our process, but I'm feeling it is firm enough to begin some of the next steps in parallel. In particular, now that we have a pretty firm outline of what the overall process is going to look like, I'd feel more comfortable asking for release manager volunteers. More on that tomorrow. --Beman
Beman Dawes wrote:
For now, maybe just generalize to "prerequisite component". If you feel inclined, go ahead an make the change.
Done. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
//svn.boost.org/svn/boost/
trunk
tags/ ... releases/ ... 1_34_1 1_35_0
branches/ release libs/ ... python serialization ...
Assuming this is the latest proposal, maybe an outside opinion of an idiot user (ie me) might help? P.S. I'm NOT a SVN user (Perforce for me, thanks). Without reading Beman's doc (and outside users probably won't) nor most of these emails, this is my first impression: - 'tags/releases' is where past releases are - excellent - 'branches' is where unstable development is happening (but really, I cheated - I read the emails to determine that for sure - because 'branches' can also mean released items, like a fork of boost or something like that, or maybe someday boost 2.0 (only supports C++0x) is released and boost 1.40 (old code base) is also released - these would be two 'branches' of boost) - trunk or branches/release is where the 'latest stable but not yet released boost' (ie the one I might experiment with to see what's coming) lives. Which is it? ie which is the 'release_candidate'? Basically, I'd like words like - 'released' (note the 'd') - 'in_progress' - 'release_candidate' or similar. But maybe that's just because I don't use SVN. And sorry to bring naming back up as a topic. Feel free to move on to other things (ie just get started), but I always find a 'first impression' is worthwhile (and only comes once). Tony
Gottlob Frege wrote:
//svn.boost.org/svn/boost/
trunk
tags/ ... releases/ ... 1_34_1 1_35_0
branches/ release libs/ ... python serialization ...
Assuming this is the latest proposal, maybe an outside opinion of an idiot user (ie me) might help?
Yes, for sure. User perspectives balance the developer perspectives.
P.S. I'm NOT a SVN user (Perforce for me, thanks).
Without reading Beman's doc (and outside users probably won't) nor most of these emails, this is my first impression:
- 'tags/releases' is where past releases are - excellent
Yep. And I've updated the trac page to reflect Dave's suggestion that it be "releases" with an "s" rather than "release".
- 'branches' is where unstable development is happening (but really, I cheated - I read the emails to determine that for sure - because 'branches' can also mean released items, like a fork of boost or something like that, or maybe someday boost 2.0 (only supports C++0x) is released and boost 1.40 (old code base) is also released - these would be two 'branches' of boost)
The "branches" name is traditional with CVS and SVN users for where unstable development is happening, so I don't think there is much potential for confusion there, except perhaps for those with no CVS or SVN exposure.
- trunk or branches/release is where the 'latest stable but not yet released boost' (ie the one I might experiment with to see what's coming) lives. Which is it? ie which is the 'release_candidate'?
Basically, I'd like words like - 'released' (note the 'd') - 'in_progress' - 'release_candidate'
or similar. But maybe that's just because I don't use SVN.
Hum... "branches/release_candidate" would certainly be more explicit than "branches/release". It is longer, but an SVN user doesn't actually have to type the name very often, so I'm not inclined to worry about that. Anyone else care to hazard an opinion on "branches/release_candidate" vs "branches/release"?
And sorry to bring naming back up as a topic. Feel free to move on to other things (ie just get started), but I always find a 'first impression' is worthwhile (and only comes once).
I don't mean to cut off repository organization and naming discussion prematurely. I do, however, want to make sure we don't stall on those topics while there are other decisions that need to be made. And, yes, "first impression" are very valuable. Thanks, --Beman
Beman Dawes wrote:
Gottlob Frege wrote:
[snip]
Basically, I'd like words like - 'released' (note the 'd') - 'in_progress' - 'release_candidate'
or similar. But maybe that's just because I don't use SVN.
Hum... "branches/release_candidate" would certainly be more explicit than "branches/release". It is longer, but an SVN user doesn't actually have to type the name very often, so I'm not inclined to worry about that.
Anyone else care to hazard an opinion on "branches/release_candidate" vs "branches/release"?
+1 for "branches/release" Shouldn't the "release_candidate"(s) be found under tags/.../RC_nnn? Won't this be a possible source of confusion? And while I'm at it ... how about "//svn/boost/trunk" => "//svn/boost/main"? / Johan
On 8/24/07, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:
Beman Dawes wrote:
Gottlob Frege wrote:
[snip]
Basically, I'd like words like - 'released' (note the 'd') - 'in_progress' - 'release_candidate'
or similar. But maybe that's just because I don't use SVN.
Hum... "branches/release_candidate" would certainly be more explicit than "branches/release". It is longer, but an SVN user doesn't actually have to type the name very often, so I'm not inclined to worry about that.
Anyone else care to hazard an opinion on "branches/release_candidate" vs "branches/release"?
+1 for "branches/release"
I would vote for "candidate" instead of "release". "release" implies that it has been released, and "release_candidate" is too long. I thought about "RC" for a bit, but I think it's too short. And, at the risk of going full circle again, I really like "stable".
Shouldn't the "release_candidate"(s) be found under tags/.../RC_nnn? Won't this be a possible source of confusion?
Well, as I understand it, there is only ever 1 "release candidate", and that is branches/release (or whatever the name will be). Libraries will be developed on their own branch, and then merged into branches/release. --Michael Fawcett
Michael Fawcett wrote:
On 8/24/07, Johan Nilsson <r.johan.nilsson@gmail.com> wrote:
Beman Dawes wrote:
[snip]
Anyone else care to hazard an opinion on "branches/release_candidate" vs "branches/release"?
+1 for "branches/release"
I would vote for "candidate" instead of "release". "release" implies that it has been released, and "release_candidate" is too long. I thought about "RC" for a bit, but I think it's too short. And, at the risk of going full circle again, I really like "stable".
Ahh, didn't see "stable" in the discussion. I like that as well.
Shouldn't the "release_candidate"(s) be found under tags/.../RC_nnn? Won't this be a possible source of confusion?
Well, as I understand it, there is only ever 1 "release candidate", and that is branches/release (or whatever the name will be). Libraries will be developed on their own branch, and then merged into branches/release.
As I understood it, there will be a single "relase candidate" _branch_, used for the "ever-available stable build". The individual release candidates would still need to be separately tagged for "official" release candidates. Imagine that someone declares the "official" release candidate for Boost 1.x.y being available under "branches/release". Now, a number of users download that candidate, testing it. The next day other users download from the same location, testing it. During that period of time something happened to the release candidate (e.g. one library was fixed). When the users report and discuss possible problems and errors with the release candidate, how can they easily know _which_ release candidate (i.e. the code state) that they are talking about without also having the candidates tagged - e.g. how can someone be able to answer the following questions: Did you notice the problem in RC_x_y_1 already? Is it fixed in RC_x_y_2? If I'm completely wrong, I'd be grateful for someone correcting me. / Johan
Johan Nilsson wrote:
As I understood it, there will be a single "relase candidate" _branch_, used for the "ever-available stable build". The individual release candidates would still need to be separately tagged for "official" release candidates.
Release candidates are a *branch/copy* : http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Releasetags and my assumption from reading is that they are locked when made available as a *release*. Michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
Michael Caisse wrote:
Johan Nilsson wrote:
As I understood it, there will be a single "relase candidate" _branch_, used for the "ever-available stable build". The individual release candidates would still need to be separately tagged for "official" release candidates.
Release candidates are a *branch/copy* :
http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Releasetags
and my assumption from reading is that they are locked when made available as a *release*.
If that's the case, I stand corrected. Doesn't really make sense to put them under "tags" if they are branches, though. However, that doesn't change the focal point of my posting; there isn't a _single_ release "candidate", or? Cheers / Johan
on Mon Aug 27 2007, "Johan Nilsson" <r.johan.nilsson-AT-gmail.com> wrote:
Michael Caisse wrote:
Johan Nilsson wrote:
As I understood it, there will be a single "relase candidate" _branch_, used for the "ever-available stable build". The individual release candidates would still need to be separately tagged for "official" release candidates.
Release candidates are a *branch/copy* :
http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Releasetags
and my assumption from reading is that they are locked when made available as a *release*.
If that's the case, I stand corrected. Doesn't really make sense to put them under "tags" if they are branches, though.
You make a release branch, then you make a copy of that branch in tags/ for each release candidate. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Mon Aug 27 2007, "Johan Nilsson" <r.johan.nilsson-AT-gmail.com> wrote:
Michael Caisse wrote:
Johan Nilsson wrote:
As I understood it, there will be a single "relase candidate" _branch_, used for the "ever-available stable build". The individual release candidates would still need to be separately tagged for "official" release candidates.
Release candidates are a *branch/copy* :
http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Releasetags
and my assumption from reading is that they are locked when made available as a *release*.
If that's the case, I stand corrected. Doesn't really make sense to put them under "tags" if they are branches, though.
You make a release branch, then you make a copy of that branch in tags/ for each release candidate.
I just read up on the SVN docs at http://svnbook.read-bean.com and realized that there's no real difference between tags and branches - just a matter of naming and usage conventions, I guess. Good to see that SVN's adapted the Perforce notion of lazy branching (i.e copying). I guess this is a bit OT, but any ideas of when (and if) SVN will support the smart branching/integration/merging capabilities of Perforce? / Johan
David Abrahams wrote:
on Mon Aug 27 2007, "Johan Nilsson" <r.johan.nilsson-AT-gmail.com> wrote:
Michael Caisse wrote:
Johan Nilsson wrote:
As I understood it, there will be a single "relase candidate" _branch_, used for the "ever-available stable build". The individual release candidates would still need to be separately tagged for "official" release candidates.
Release candidates are a *branch/copy* :
http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Releasetags
and my assumption from reading is that they are locked when made available as a *release*.
If that's the case, I stand corrected. Doesn't really make sense to put them under "tags" if they are branches, though.
You make a release branch, then you make a copy of that branch in tags/ for each release candidate.
I just read up on the SVN docs at http://svnbook.red-bean.com/ and realized that there's no real difference between tags and branches - just a matter of naming and usage conventions, I guess. Good to see that SVN's adapted the Perforce notion of lazy branching (i.e copying). I guess this is a bit OT, but any ideas of when (and if) SVN will support the smart branching/integration/merging capabilities of Perforce? / Johan
on Wed Aug 29 2007, "Johan Nilsson" <r.johan.nilsson-AT-gmail.com> wrote:
I guess this is a bit OT, but any ideas of when (and if) SVN will support the smart branching/integration/merging capabilities of Perforce?
It's planned for the next revision, and in the meantime we have svnmerge.py which does the same job. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Hi! Johan Nilsson schrieb:
e.g. how can someone be able to answer the following questions: Did you notice the problem in RC_x_y_1 already? Is it fixed in RC_x_y_2?
Well, use revision numbers. Or I think you will end up with one tag for every revision of the release branch which I see no point in. Frank
Frank Birbacher wrote:
Hi!
Johan Nilsson schrieb:
e.g. how can someone be able to answer the following questions: Did you notice the problem in RC_x_y_1 already? Is it fixed in RC_x_y_2?
Well, use revision numbers. Or I think you will end up with one tag for every revision of the release branch which I see no point in.
Revision numbers are less user-friendly. I don't believe that "every revision" of the release branch would have to be tagged, only the official release candidates. Also, the RC_ tags could be removed after the official release to clean up among the tags. / Johan
Frank Birbacher wrote:
Hi!
Johan Nilsson schrieb:
e.g. how can someone be able to answer the following questions: Did you notice the problem in RC_x_y_1 already? Is it fixed in RC_x_y_2?
Well, use revision numbers. Or I think you will end up with one tag for every revision of the release branch which I see no point in.
Revision numbers are less user-friendly. I don't believe that "every revision" of the release branch would have to be tagged, only the official release candidates. Also, the RC_ tags could be removed after the official release to clean up among the tags. / Johan
Johan Nilsson wrote:
As I understood it, there will be a single "relase candidate" _branch_, used for the "ever-available stable build". The individual release candidates would still need to be separately tagged for "official" release candidates.
Imagine that someone declares the "official" release candidate for Boost 1.x.y being available under "branches/release". Now, a number of users download that candidate, testing it. The next day other users download from the same location, testing it. During that period of time something happened to the release candidate (e.g. one library was fixed). When the users report and discuss possible problems and errors with the release candidate, how can they easily know _which_ release candidate (i.e. the code state) that they are talking about without also having the candidates tagged - e.g. how can someone be able to answer the following questions: Did you notice the problem in RC_x_y_1 already? Is it fixed in RC_x_y_2?
If I'm completely wrong, I'd be grateful for someone correcting me.
Subversion revision numbers are global and atomic. They can simply refer to the revision they have. I think of tags as simply a convenient alias for a folder at a revision under Subversion. - Michael Marcin
So what is trunk for? On 8/24/07, Beman Dawes <bdawes@acm.org> wrote:
Gottlob Frege wrote:
//svn.boost.org/svn/boost/
trunk
tags/ ... releases/ ... 1_34_1 1_35_0
branches/ release libs/ ... python serialization ...
The "branches" name is traditional with CVS and SVN users for where unstable development is happening, so I don't think there is much potential for confusion there, except perhaps for those with no CVS or SVN exposure.
Gottlob Frege wrote:
So what is trunk for?
LOL - we've come full circle. Actually, I do see a use for the trunk. Basically it would be for those who don't want to do developement on a branch. This could easily occur of the changes one wants to make are not very big. It could be because one is just getting familiar with SVN and doesn't want to muck things up. (easy to do). It could be because the developer has his local copy on his machine and the changes he's making are going to last a short time so he doesn't want/need to create temporary branch. In short, the trunk would be the default development branch for those that don't want/need a separate branch. Of course, this raises the question - What is the point of testing on the trunk? Robert Ramey
On 8/24/07, Beman Dawes <bdawes@acm.org> wrote:
Gottlob Frege wrote:
//svn.boost.org/svn/boost/
trunk
tags/ ... releases/ ... 1_34_1 1_35_0
branches/ release libs/ ... python serialization ...
The "branches" name is traditional with CVS and SVN users for where unstable development is happening, so I don't think there is much potential for confusion there, except perhaps for those with no CVS or SVN exposure.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Gottlob Frege wrote:
So what is trunk for?
LOL - we've come full circle. Actually, I do see a use for the trunk.
As describe at <http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Trunk>: * Trunk - The main development and test location.
Basically it would be for those who don't want to do developement on a branch.
The default would be to develop on the trunk, but anyone is free to develop on a branch. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
on Fri Aug 24 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Robert Ramey wrote:
Gottlob Frege wrote:
So what is trunk for?
LOL - we've come full circle. Actually, I do see a use for the trunk.
As describe at <http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Trunk>:
* Trunk - The main development and test location.
Basically it would be for those who don't want to do developement on a branch.
The default would be to develop on the trunk, but anyone is free to develop on a branch.
I hope not. I want to have an "avoid breakage on the trunk" policy. In other words, before you mix your code "in public" with the rest of our recent development, it should have been tested (at least by someone) in context against the rest of the trunk. Otherwise, we could easily end up with multi-library problems/incompatibilities on the trunk, at which point it becomes the whole community's problem. I really want individual library authors to be responsible for the clean state of the trunk, and that means checking in all your partially-completed and/or untested work on a branch. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
On 8/26/07, David Abrahams <dave@boost-consulting.com> wrote:
on Fri Aug 24 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
Robert Ramey wrote:
Gottlob Frege wrote:
So what is trunk for?
LOL - we've come full circle. Actually, I do see a use for the trunk.
As describe at <http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Trunk>:
* Trunk - The main development and test location.
Basically it would be for those who don't want to do developement on a branch.
The default would be to develop on the trunk, but anyone is free to develop on a branch.
I hope not. I want to have an "avoid breakage on the trunk" policy. In other words, before you mix your code "in public" with the rest of our recent development, it should have been tested (at least by someone) in context against the rest of the trunk. Otherwise, we could easily end up with multi-library problems/incompatibilities on the trunk, at which point it becomes the whole community's problem. I really want individual library authors to be responsible for the clean state of the trunk, and that means checking in all your partially-completed and/or untested work on a branch.
I'm still confused - are you saying that a developer works like this: - codes in branch - merges some code branch -> trunk - merges trunk -> branch/release (or whatever it is called) why not skip trunk? what is the difference between code in trunk and release? P.S. I guess I'm assuming they merge release -> branch before checking in to branch. (So they know they're new code is compatible with release). Or is that what trunk is for, somehow? Tony
on Sun Aug 26 2007, "Gottlob Frege" <gottlobfrege-AT-gmail.com> wrote:
I'm still confused - are you saying that a developer works like this:
- codes in branch - merges some code branch -> trunk
Yes.
- merges trunk -> branch/release (or whatever it is called)
Usually not. That would be the release manager's job.
why not skip trunk? what is the difference between code in trunk and release?
When the release manager tags a release candidate, that becomes "release" and more code can be merged to trunk. If this sounds a lot like what we do today, it's because I don't see a problem with it ;-)
P.S. I guess I'm assuming they merge release -> branch before checking in to branch. (So they know they're new code is compatible with release). Or is that what trunk is for, somehow?
If you've been on a branch for a while, merge trunk -> branch and test locally before merging branch -> trunk, so the chance of new developments breaking the build when you merge to trunk is minimized. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
On 8/27/07, David Abrahams <dave@boost-consulting.com> wrote:
on Sun Aug 26 2007, "Gottlob Frege" <gottlobfrege-AT-gmail.com> wrote:
I'm still confused - are you saying that a developer works like this:
- codes in branch - merges some code branch -> trunk
Yes.
- merges trunk -> branch/release (or whatever it is called)
Usually not. That would be the release manager's job.
Ah, right. I forgot about the release manager. That makes sense. Thanks. Tony
Hi! David Abrahams schrieb:
If you've been on a branch for a while, merge trunk -> branch and test locally before merging branch -> trunk, so the chance of new developments breaking the build when you merge to trunk is minimized.
Now, with all the merging one important information is missing. The part "merge your branch to the trunk" does not cover all neccessary information: a merge envolves _three_ "points" (point = location with revision number in svn). You can start a branch, develop in it, merge the range trunk@branch-rev trunk@HEAD to your branch@HEAD and immediately (without new commits to trunk) merge the range trunk@HEAD to branch@HEAD to trunk@HEAD. Then you need to convey the revision number "HEAD" for further merges "trunk -> branch". This is what Sebastian Redl is warning about in the thread "[SVN] Repository branches/libs experiments" (started on 08/25/07). I'm quoting him here: <QUOTE> One thing that is important to distinguish is release branches (the state of a major release, for bugfixing and point releases) and development branches (sandboxes for developing stuff). You can merge trunk changes over to release branches (and vice versa, if a bug is fixed on the release branch first), but you must never merge trunk changes to development branches! The changes from these merges would be picked up by the diffing of the branch's initial and final states. This means that the merging would try to apply changes to the trunk that were already made, hopelessly confusing the merger and making the merging very, very difficult. So don't do it. If you've spent so much time on a development that your patch is hopelessly out of date, you do this: create another branch based on the most recent trunk state, merge the changes of your original branch to this new one as you would merge them to the trunk, then fix everything that doesn't work. Then, merge the changes done on this new branch to the trunk. </QUOTE> To K.I.S.S. one should not merge the trunk changes into his development branch. I agree on this unless we employ svnmerge ( http://trac.edgewall.org/wiki/SvnMerge ). And I actually would prefer svnmerge which is likely to become part of svn in release 1.5. Frank
Hi! David Abrahams schrieb:
If you've been on a branch for a while, merge trunk -> branch and test locally before merging branch -> trunk, so the chance of new developments breaking the build when you merge to trunk is minimized.
Now, with all the merging one important information is missing. The part "merge your branch to the trunk" does not cover all neccessary information: a merge envolves _three_ "points" (point = location with revision number in svn). You can start a branch, develop in it, merge the range trunk@branch-rev trunk@HEAD to your branch@HEAD and immediately (without new commits to trunk) merge the range trunk@HEAD to branch@HEAD to trunk@HEAD. Then you need to convey the revision number "HEAD" for further merges "trunk -> branch". This is what Sebastian Redl is warning about in the thread "[SVN] Repository branches/libs experiments" (started on 08/25/07). I'm quoting him here: <QUOTE> One thing that is important to distinguish is release branches (the state of a major release, for bugfixing and point releases) and development branches (sandboxes for developing stuff). You can merge trunk changes over to release branches (and vice versa, if a bug is fixed on the release branch first), but you must never merge trunk changes to development branches! The changes from these merges would be picked up by the diffing of the branch's initial and final states. This means that the merging would try to apply changes to the trunk that were already made, hopelessly confusing the merger and making the merging very, very difficult. So don't do it. If you've spent so much time on a development that your patch is hopelessly out of date, you do this: create another branch based on the most recent trunk state, merge the changes of your original branch to this new one as you would merge them to the trunk, then fix everything that doesn't work. Then, merge the changes done on this new branch to the trunk. </QUOTE> To K.I.S.S. one should not merge the trunk changes into his development branch. I agree on this unless we employ svnmerge ( http://trac.edgewall.org/wiki/SvnMerge ). And I actually would prefer svnmerge which is likely to become part of svn in release 1.5. Frank
on Wed Aug 29 2007, Frank Birbacher <bloodymir.crap-AT-gmx.net> wrote:
David Abrahams schrieb:
If you've been on a branch for a while, merge trunk -> branch and test locally before merging branch -> trunk, so the chance of new developments breaking the build when you merge to trunk is minimized.
Now, with all the merging one important information is missing. The part "merge your branch to the trunk" does not cover all neccessary information: a merge envolves _three_ "points" (point = location with
<snip correct but complex and arguably obsolete procedure>
To K.I.S.S. one should not merge the trunk changes into his development branch. I agree on this unless we employ svnmerge ( http://trac.edgewall.org/wiki/SvnMerge ). And I actually would prefer svnmerge which is likely to become part of svn in release 1.5.
Yeah, I've been repeatedly suggesting we use it so we don't have to deal with the complexities of the three-point merge. CVS actually has basically the same model, but even for those of us who are comfortable with branching and merging it's too painful. So if we use svnmerge we can just do what I wrote above. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
- A sort of overall comment. Unless I missed something (which is very likely), the preferred way of working with a library is to checkout the "trunk" and work locally with "your" library. This could easily cause the trunk to get so instable that fixing it before merging to "release" might become a serious ... problem, it you do not have some policies/guidelines on how to work, e.g.: (when working against the trunk) -- Do not check-in code to the trunk that does not pass all tests locally (i.e. the library's own tests). If you need to perform large refactorings that take an extended period of time, and you want to be able to check-in work in progress, you should always perform your work on a separate library branch. -- Always refresh your copy of the trunk and re-run your tests before checking in your code (to lessen the chance that other recent library updates breaks your code). - Concerning the repo organization: -- Release tags: Having all releases and their associated release candidates at the same level will probably become cluttered after some amount of time. Did you consider the following: tags/ release/ 1_35_0/ RC_1_35_0_n/ RC_1_35_0_n+1/ final/ Or do you intend to remove the "RC" tags once released? -- "trunk" => "main" (personal preference) -- "branches/release" => "branches/stable" (as Michael Fawcett mentioned). / Johan
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users.
I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0.
I don't think I see the answers to the below question that I've previous posted: 1. The procedure for merging to release-ready tree needs more details -- if the procedure is painful, then authors just won't merge anything. Say a great new feature is developed on trunk, but causes regression on a obscure platform. Author failed to fix that regression after reasonable effect, and platform experts failed as well. Can this change go to release tree still? 2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree. Week later, a serious bug is found in another library. Is there a place where that bug can be fixed? Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released? 3. Even assuming release-ready tree haven't got any big changes -- what is the planned procedure for fixing issues discovered on release-ready tree? Trunk might be in the middle on the next big change, so a fix can either (1) be made on brunch and then merged, or (2) be made on release-ready tree directly. (1) requires on-demand testing of branches. Is (2) the way to go? Concerning (1), your definition of release ready will prevent merge if there even a single regression. And (2)-(3) are not addressed at all, as far as I see. - Volodya
Vladimir Prus wrote:
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users.
I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0.
I don't think I see the answers to the below question that I've previous posted:
1. The procedure for merging to release-ready tree needs more details -- if the procedure is painful, then authors just won't merge anything. Say a great new feature is developed on trunk, but causes regression on a obscure platform. Author failed to fix that regression after reasonable effect, and platform experts failed as well. Can this change go to release tree still?
I think this is something the the Release Manager and only the Release Manager should do. Although the most convenient way to do this is still the subject of experimentation I would envision the following: a) A library author presents argument/evidence that his changes in the trunk or in a private branch will not break anything in the next release. b) The release manager evaluates the request and either accepts it or rejects it with an explanation or counter request for more testing or whatever. c) If its accepted, the release manager merges the authors changes from whereever they have been checked in, maybe runs some library specific test on his own. d) The release manager then generates the tarball and uploads it the designated area and request full testing on it. e) If the testing results show an improvement over the current version, anouncement is made and the latest tarball is designated the most recent official release. f) The release manager has the descretion to bundle more than one set of changes in a release. He might want to do this to save time if the changes are ready at the same time and he sees them as unlikely to conflict. I order to accomplish a) above with the current tool setup, The following kind of process is envisioned. i) The developer keeps a copy of the next release on his machine. ii) He switches the directories corresponding to his library over to the place where he has checked in his changes. This might be the trunk or a private release branch. iii) He runs local tests. I've created library_status with this purpose in mind. iv) If he's satisfied and want's help testing on other platforms. He finds a willing collaborator to do the test same test on HIS platform. Note that this testing is quite fast as its only one library. Personally I would recommend that this testing be for all likely build variations <variant>build/release, <link>static,shared, <threading>multi,single The tester can report the results back to the author. Currently there is no documented way to do this conveniently. But I feel this could be done with little effort. Again I created library_status to permit browsing of the accumulated results in a convenient manner.
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree.
At the option of the release manager, the changes are rolled back or the bug is fixed in the release-ready tree.
Week later, a serious bug is found in another library. Is there a place where that bug can be fixed?
If the bug is found in the release ready tree, the release manager has the same two alternatives described about. Ask for fix or roll back. It's up to him
Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released?
Release 1.35.1 is released when the released manager feels that its a significant improvement over the previous release. He has the authority to merge in changes and rollback.
3. Even assuming release-ready tree haven't got any big changes -- what is the planned procedure for fixing issues discovered on release-ready tree?
Similar to the testing which has been done on the release candidate in the past. The difference is that it would only need be done when requested by the release manager after he has merged something in.
Trunk might be in the middle on the next big change, so a fix can either (1) be made on brunch and then merged, or
(2) be made on release-ready tree directly.
I would not expect the release manager to approve this and merge in such changes unless they are of a very small and/or trivial nature. He will have to weigh the risk as he's stuck with the consequences. (1) requires on-demand testing of branches. Is (2) the way to go? Yes it is. For now we can just do it in the informal/ad-hoc way described above. Assuming it works out, this process can be made more automated.
Concerning (1), your definition of release ready will prevent merge if there even a single regression.
Generally this is true. The release manager would have the option of making a change in the release-ready branch. The occurence of this situation signals a like interface-breaking change so rolling back might seem drastic, but its likely that the change has larger implications that one test failure shows. So if I were release manager, I would be predisposed to just punting back to the library author(s) to address. *** As a "test" of this new procedure, I think we should try it with 1.34.2. This would be targeted for 15 October 2007 This could/include a) Joaquins Multi-index which he claims to have tested against 1.34.1 b) build system corrections/improvements c) Any other libraries whose authors want to submit evidence that their recent changes haven't broken anything. The only question would be the recruitment of the release manager - LOL Robert Ramey
Robert Ramey wrote:
Vladimir Prus wrote:
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users.
I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0.
I don't think I see the answers to the below question that I've previous posted:
1. The procedure for merging to release-ready tree needs more details -- if the procedure is painful, then authors just won't merge anything. Say a great new feature is developed on trunk, but causes regression on a obscure platform. Author failed to fix that regression after reasonable effect, and platform experts failed as well. Can this change go to release tree still?
I think this is something the the Release Manager and only the Release Manager should do. Although the most convenient way to do this is still the subject of experimentation I would envision the following:
Well, "Release Manager decides" is an acceptable policy, but then we need to leave this option option in the guidelines. As written, such merge is just disallowed.
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree.
At the option of the release manager, the changes are rolled back or the bug is fixed in the release-ready tree.
Sorry, what bug? There's no bug at this point yet.
Week later, a serious bug is found in another library. Is there a place where that bug can be fixed?
If the bug is found in the release ready tree, the release manager has the same two alternatives described about. Ask for fix or roll back. It's up to him
Roll back what? Let the try again. 1.35 is released *already*, and then release branch has a big change in library XXX -- performed with all the procedures. Now there's a bug in library YYY, and the author has a one-line fix ready. If that fix is committed to release branch, we have a version of Boost with one small fix, and big change, so it's now not a safe upgrade for users. Clearly, asking the author of XXX to revert his changes is wrong -- he followed every policy.
Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released?
Release 1.35.1 is released when the released manager feels that its a significant improvement over the previous release. He has the authority to merge in changes and rollback.
I think it's very hard for release manager to predict what kind of bugs will be discovered. So, there's always the change that a big change is followed by a small bugfix, leaving a tree that might be too early for new release, but already not suitable as bug-fix release.
3. Even assuming release-ready tree haven't got any big changes -- what is the planned procedure for fixing issues discovered on release-ready tree?
Similar to the testing which has been done on the release candidate in the past.
Erm, that is, announce RC and then wait for comments? No formal testing?
The difference is that it would only need be done when requested by the release manager after he has merged something in.
Trunk might be in the middle on the next big change, so a fix can either (1) be made on brunch and then merged, or
(2) be made on release-ready tree directly.
I would not expect the release manager to approve this and merge in such changes unless they are of a very small and/or trivial nature. He will have to weigh the risk as he's stuck with the consequences.
(1) requires on-demand testing of branches. Is (2) the way to go?
Yes it is. For now we can just do it in the informal/ad-hoc way described above. Assuming it works out, this process can be made more automated.
Concerning (1), your definition of release ready will prevent merge if there even a single regression.
Generally this is true. The release manager would have the option of making a change in the release-ready branch.
The occurence of this situation signals a like interface-breaking change so rolling back might seem drastic, but its likely that the change has larger implications that one test failure shows. So if I were release manager, I would be predisposed to just punting back to the library author(s) to address.
So, obscure version of obscure compiler can block all progress.
*** As a "test" of this new procedure, I think we should try it with 1.34.2.
This would be targeted for 15 October 2007
I can't parse your "would". Is it -- "this would be targeted, ... if", or "it can be targeted", or "it will be targeted". IOW, are you just proposing this date, or is it set somewhere already?
This could/include
a) Joaquins Multi-index which he claims to have tested against 1.34.1
b) build system corrections/improvements
c) Any other libraries whose authors want to submit evidence that their recent changes haven't broken anything.
The only question would be the recruitment of the release manager - LOL
Clearly, an email in a thread with 50 emails is not a best way to recruit a release manager. I don't see any evidence a release manager is being sought. - Volodya
Vladimir Prus wrote:
Robert Ramey wrote:
I think this is something the the Release Manager and only the Release Manager should do. Although the most convenient way to do this is still the subject of experimentation I would envision the following:
Well, "Release Manager decides" is an acceptable policy, but then we need to leave this option option in the guidelines.
Agreed.
Roll back what? Let the try again. 1.35 is released *already*, and then release branch has a big change in library XXX -- performed with all the procedures.
I assume that "release branch" means 1.36 at this point.
Now there's a bug in library YYY, and the author has a one-line fix ready. If that fix is committed to release branch, we have a version of Boost with one small fix, and big change, so it's now not a safe upgrade for users.
Assuming both changes have followed procedures its no different than anything other change.
Clearly, asking the author of XXX to revert his changes is wrong -- he followed every policy.
Agreed that should never happen and I see no situation where that would
Release-ready tree already has source-incompatible change to other library?
How so? if both changes have been subjected to the same procedure, the release-ready tree is still release ready.
In other words -- from which tree is 1.35.1 going to
be released?
The release-ready tree - as always. It will contain at least two changes. One large change on library XXX and one small bug fix on library XXX. Depending on the judgment of the release manager, it might contain other changes as well.
Release 1.35.1 is released when the released manager feels that its a significant improvement over the previous release. He has the authority to merge in changes and rollback.
I think it's very hard for release manager to predict what kind of bugs will be discovered. So, there's always the change that a big change is followed by a small bugfix, leaving a tree that might be too early for new release, but already not suitable as bug-fix release.
My view can be summarized as follows: All changes are added and tested one (or a small number) at a time. If it fails release test then either a fix is made or the change is rolled back. But the fixed point is that the release-branch is always "release-able" except for the tiny amount of time while the release manager is deciding whether a failed test should imply a fix or a roll back. While this thought process is occurring, (maybe a day?). The release branch is temporarily blocked and not releaseale. Other changes are not rolled in until the current situation is resolved and the release branch is releaseable again.
3. Even assuming release-ready tree haven't got any big changes -- what is the planned procedure for fixing issues discovered on release-ready tree?
Similar to the testing which has been done on the release candidate in the past.
Erm, that is, announce RC and then wait for comments? No formal testing?
As each change is merged into the release ready branch, the release manager would request testing on this branch. Meanwhile he doesn't make any changes on this branch. After he has enough test results and the results indicate and improvement over the current release, it make the same tarball that has been tested the "official" one that users download.
The occurence of this situation signals a like interface-breaking change so rolling back might seem drastic, but its likely that the change has larger implications that one test failure shows. So if I were release manager, I would be predisposed to just punting back to the library author(s) to address.
So, obscure version of obscure compiler can block all progress.
A change which breaks an interface which other components depend upon means that change can't be merged in. It blocks progress on that component. If through oversight, such a component is merged into the release-ready branch and this oversight is discovered during release tarball testing, the component has to be rolled out while the component author and its users reach some sort of consensus. In the mean time, progress on that component (and only that component is stalled. Under the current system, such a breaking change breaks a lot of other stuff and blocks progress on all the stuff it breaks. for an "obscure version of obscure compiler" the release manager could let in the change anyway. The criteria for a release is not perfection. The criteria is a "measureable improvement over the current release"
As a "test" of this new procedure, I think we should try it with 1.34.2.
This would be targeted for 15 October 2007
I can't parse your "would". Is it -- "this would be targeted, ... if", or "it can be targeted", or "it will be targeted". IOW, are you just proposing this date, or is it set somewhere already?
LOL - I'm proposing the following. Somehow a release manager be selected His task will be to a) create branch for the 1.34.2 release b) merge in ehancements according to the above procedure c) thereby maintain a release-ready branch d) his goal will to be able to make available to the public a tarball for version 1.34.2 on or before 15 October 2007 e) the above suggests to me that he would stop merging in changes on or before 8 October - but of course that would be his decision. Of course someone will loudly complain that its too soon for HIS changes or that he was ready but they couldn't be tested soon enough or that his changes got rolled back because of a trivial to fix bug. Such behavior a person will automatically make himself elgible to be the manager of the NEXT release.
The only question would be the recruitment of the release manager - LOL
Clearly, an email in a thread with 50 emails is not a best way to recruit a release manager. I don't see any evidence a release manager is being sought.
I have no idea how a release manager gets selected. Or by whom. Clearly I'm arguing for a different role for the release manager than he has had in the past. In large part I'm inspired by what I see as the success of the "review manager" in the context of a library. The review manager has a clearly defined responsability and requisite authority to make an important decision. I attribute to this (unique) system boost's singular success. I'm arguing that the Release manager have analagous responsability and authority in the area of admiting changes to the release. Robert Ramey
At 12:59 AM +0400 9/2/07, Vladimir Prus wrote:
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree. Week later, a serious bug is found in another library. Is there a place where that bug can be fixed? Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released?
Being a user of boost, I would suggest the answers be a. The bug fix should be made to the release-ready branch, assuming it satisfies the processes for doing so. Since the bug is described as serious, the relevant library author has a pretty strong incentive for getting the bug fix through the release submission process. b. By default, there is no 1.35.1. This might be considered contentious by some, so I will give some arguments in support of that position. Boost is an open source project. If a user needs a bug fix back ported to an earlier version (even the latest release), that user is free to do it themselves, or convince someone else to do it for them, possibly by hire. If there are enough users for a particular release wanting bug fixes back ported, they could even band together and amortize the cost of "professional" support. The author of the library containing the bug might choose to do that backport and make it available as a branch that users can merge from, but I don't think that should be a requirement. Who would decide what bug fixes go into a 1.35.1,2,3,... release? Different users may have different needs there. One user's show stopper bug might be in another user's "too risky" category. Boost is an all volunteer effort. It is producing stuff that is clearly useful to a lot of folks, and of very high quality. I think this volunteer effort should remain focused on that library development, and not get bogged down in dealing with more configuration management issues. Keep moving toward future improvements, and don't worry to much about past releases.
Vladimir Prus wrote:
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users.
I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0.
I don't think I see the answers to the below question that I've previous posted:
1. The procedure for merging to release-ready tree needs more details -- if the procedure is painful, then authors just won't merge anything.
Yes, the easier the procedure is, the better. We are strongly urging developers to become familiar with synmerge.py, and use it to simplify branch management See http://www.orcaware.com/svn/wiki/Svnmerge.py. Incidentally, Subversion 1.5 will build in the functionality of svnmerge.py.
Say a great new feature is developed on trunk, but causes regression on a obscure platform. Author failed to fix that regression after reasonable effect, and platform experts failed as well. Can this change go to release tree still?
Sure, as long as it is marked up as an expected failure. There are no plans to change the markup procedures for failing tests AFAIK.
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree. Week later, a serious bug is found in another library. Is there a place where that bug can be fixed? Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released?
Up to the release manager, perhaps after discussion on the. Between the way we tag releases and the facilities of Subversion, the release manager will be able to start from wherever is best. My guess is the the starting point is always the prior release, so the just merged change gets moved aside until the next 1.36.0 release.
3. Even assuming release-ready tree haven't got any big changes -- what is the planned procedure for fixing issues discovered on release-ready tree? Trunk might be in the middle on the next big change, so a fix can either (1) be made on brunch and then merged, or (2) be made on release-ready tree directly. (1) requires on-demand testing of branches. Is (2) the way to go?
Release manager decides. (1) is preferred because it minimizes change of release branch becoming unstable, but (2) may be acceptable to the release manager if working copy testing has been extensive enough.
Concerning (1), your definition of release ready will prevent merge if there even a single regression.
I'll change the wording to make it clear markups are still allowed.
And (2)-(3) are not addressed at all, as far as I see.
We don't have to have procedures in place for every possible contingency. Let's get started on a release; we can refine procedures as experience dictates. Thanks, --Beman
Beman Dawes wrote:
Vladimir Prus wrote:
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users.
I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0.
I don't think I see the answers to the below question that I've previous posted:
1. The procedure for merging to release-ready tree needs more details -- if the procedure is painful, then authors just won't merge anything.
Yes, the easier the procedure is, the better.
We are strongly urging developers to become familiar with synmerge.py, and use it to simplify branch management See http://www.orcaware.com/svn/wiki/Svnmerge.py.
Incidentally, Subversion 1.5 will build in the functionality of svnmerge.py.
1. For the branch layout that is proposed, you don't need svnmerge, a scrap of paper, of a wiki page, or a manually maintained property will work just fine. 2. What made you think that SVN 1.5 will be compatible with svnmerge in any way? Importantly, I can find any indication that properties set by svnmerge can be of direct use to SVN 1.5. I'd be happy to be proved wrong, BTW.
Say a great new feature is developed on trunk, but causes regression on a obscure platform. Author failed to fix that regression after reasonable effect, and platform experts failed as well. Can this change go to release tree still?
Sure, as long as it is marked up as an expected failure. There are no plans to change the markup procedures for failing tests AFAIK.
Ok, this makes sense.
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree. Week later, a serious bug is found in another library. Is there a place where that bug can be fixed? Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released?
Up to the release manager, perhaps after discussion on the. Between the way we tag releases and the facilities of Subversion, the release manager will be able to start from wherever is best. My guess is the the starting point is always the prior release, so the just merged change gets moved aside until the next 1.36.0 release.
"Moved aside" means "reverted"? They are already on release branch. This seems weird, this means the work spend merging to release branch is wasted.
3. Even assuming release-ready tree haven't got any big changes -- what is the planned procedure for fixing issues discovered on release-ready tree? Trunk might be in the middle on the next big change, so a fix can either (1) be made on brunch and then merged, or (2) be made on release-ready tree directly. (1) requires on-demand testing of branches. Is (2) the way to go?
Release manager decides. (1) is preferred because it minimizes change of release branch becoming unstable, but (2) may be acceptable to the release manager if working copy testing has been extensive enough.
Okay.
Concerning (1), your definition of release ready will prevent merge if there even a single regression.
I'll change the wording to make it clear markups are still allowed.
And (2)-(3) are not addressed at all, as far as I see.
We don't have to have procedures in place for every possible contingency. Let's get started on a release; we can refine procedures as experience dictates.
Well, to get started on a release you only have to find a release manager, and create a release branch. The rest of this discussion, such as how to name directories, can well happen in parallel with 1.35 release process. - Volodya
on Wed Sep 05 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
Beman Dawes wrote:
Vladimir Prus wrote:
Beman Dawes wrote:
The Development and Release Practices trac wiki page has been updated. See http://svn.boost.org/trac/boost/wiki/ImprovingPractices
The most important changes were refinements of the repository organization and addition of more specific procedures for merging from the trunk to the next release. The merging is described in terms of TortoiseSVN. It would be helpful if someone familiar with command line svn provided an equivalent set of instructions for command line users.
I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0.
I don't think I see the answers to the below question that I've previous posted:
1. The procedure for merging to release-ready tree needs more details -- if the procedure is painful, then authors just won't merge anything.
Yes, the easier the procedure is, the better.
We are strongly urging developers to become familiar with synmerge.py, and use it to simplify branch management See http://www.orcaware.com/svn/wiki/Svnmerge.py.
Incidentally, Subversion 1.5 will build in the functionality of svnmerge.py.
1. For the branch layout that is proposed, you don't need svnmerge, a scrap of paper, of a wiki page, or a manually maintained property will work just fine.
Why do that when svnmerge takes care of it for you?
2. What made you think that SVN 1.5 will be compatible with svnmerge in any way?
What made you think Beman thought that?
Importantly, I can find any indication that properties set by svnmerge can be of direct use to SVN 1.5. I'd be happy to be proved wrong, BTW.
I'm sure you're right. I don't think anyone thought differently, though.
Say a great new feature is developed on trunk, but causes regression on a obscure platform. Author failed to fix that regression after reasonable effect, and platform experts failed as well. Can this change go to release tree still?
Sure, as long as it is marked up as an expected failure. There are no plans to change the markup procedures for failing tests AFAIK.
Ok, this makes sense.
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree. Week later, a serious bug is found in another library. Is there a place where that bug can be fixed? Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released?
Up to the release manager, perhaps after discussion on the. Between the way we tag releases and the facilities of Subversion, the release manager will be able to start from wherever is best. My guess is the the starting point is always the prior release, so the just merged change gets moved aside until the next 1.36.0 release.
"Moved aside" means "reverted"? They are already on release branch. This seems weird, this means the work spend merging to release branch is wasted.
Yeah, that would be silly. Obviously you create a copy of the 1.35.0 tag and start with that for 1.35.1. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
I'm trying to restrict the process to things we can do right away, so we can get started on 1.35.0.
I don't think I see the answers to the below question that I've previous posted:
1. The procedure for merging to release-ready tree needs more details -- if the procedure is painful, then authors just won't merge anything.
Yes, the easier the procedure is, the better.
We are strongly urging developers to become familiar with synmerge.py, and use it to simplify branch management See http://www.orcaware.com/svn/wiki/Svnmerge.py.
Incidentally, Subversion 1.5 will build in the functionality of svnmerge.py.
1. For the branch layout that is proposed, you don't need svnmerge, a scrap of paper, of a wiki page, or a manually maintained property will work just fine.
Why do that when svnmerge takes care of it for you?
I'm saying that presence, or lack of, svnmerge, is incidental to the current discussion. Doing merge in SVN is easy part.
2. What made you think that SVN 1.5 will be compatible with svnmerge in any way?
What made you think Beman thought that?
Importantly, I can find any indication that properties set by svnmerge can be of direct use to SVN 1.5. I'd be happy to be proved wrong, BTW.
I'm sure you're right. I don't think anyone thought differently, though.
Because then, starting with svnmerge now might not be best idea -- we might as well wait for svn 1.5.
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree. Week later, a serious bug is found in another library. Is there a place where that bug can be fixed? Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released?
Up to the release manager, perhaps after discussion on the. Between the way we tag releases and the facilities of Subversion, the release manager will be able to start from wherever is best. My guess is the the starting point is always the prior release, so the just merged change gets moved aside until the next 1.36.0 release.
"Moved aside" means "reverted"? They are already on release branch. This seems weird, this means the work spend merging to release branch is wasted.
Yeah, that would be silly. Obviously you create a copy of the 1.35.0 tag and start with that for 1.35.1.
Which is not said in the document. - Volodya
on Thu Sep 06 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
2. What made you think that SVN 1.5 will be compatible with svnmerge in any way?
What made you think Beman thought that?
Are you not going to answer that?
Importantly, I can find any indication that properties set by svnmerge can be of direct use to SVN 1.5. I'd be happy to be proved wrong, BTW.
I'm sure you're right. I don't think anyone thought differently, though.
Because then, starting with svnmerge now might not be best idea -- we might as well wait for svn 1.5.
What is your argument against using svnmerge.py before svn 1.5 is available? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
on Thu Sep 06 2007, Roland Schwarz <roland.schwarz-AT-chello.at> wrote:
David Abrahams wrote:
What is your argument against using svnmerge.py before svn 1.5 is available?
May I dare to ask an innocent question? Would users of gui tools such as TortoiseSVN also need to use this tool?
Yes, we would strongly encourage it.
Would it be usable together with Tortoise?
I think all the information is here: http://www.orcaware.com/svn/wiki/Svnmerge.py You can surely use it "with" Tortoise, but I think you can only do merges from the command line if you want to get maximum benefit and avoid confusing other peoples' merges. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Thu Sep 06 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
2. What made you think that SVN 1.5 will be compatible with svnmerge in any way?
What made you think Beman thought that?
Are you not going to answer that?
Unless SVN 1.5 is compatible with svnmerge in any way, then the fact that merge tracking is implemented in SVN 1.5 is rather irrelevant to our using or not using of svnmerge. It can as well be said that Perforce, svk, bzr, git, monotone and mercurial have merge tracking -- that's true, but has no bearing to anything. So the only way to interpret SVN 1.5 remark is to assume that it's some argument in favour of svnmerge.
Importantly, I can find any indication that properties set by svnmerge can be of direct use to SVN 1.5. I'd be happy to be proved wrong, BTW.
I'm sure you're right. I don't think anyone thought differently, though.
Because then, starting with svnmerge now might not be best idea -- we might as well wait for svn 1.5.
What is your argument against using svnmerge.py before svn 1.5 is available?
The fact that interfaces of svnmerge.py and svn 1.5 will be different, and any instructions written for svnmerge.py will have to be rewritten, and that developers will be confused when we switch, and unless you force everybody to merge all branches right before switch to 1.5, you'll have branches that have both svnmerge.py and svn 1.5 mergeinfo, and it's doubtfull that either tool will be able to handle that. - Volodya
Vladimir Prus wrote:
David Abrahams wrote:
on Thu Sep 06 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
2. What made you think that SVN 1.5 will be compatible with svnmerge in any way? What made you think Beman thought that? Are you not going to answer that?
Unless SVN 1.5 is compatible with svnmerge in any way, then the fact that merge tracking is implemented in SVN 1.5 is rather irrelevant to our using or not using of svnmerge. It can as well be said that Perforce, svk, bzr, git, monotone and mercurial have merge tracking -- that's true, but has no bearing to anything. So the only way to interpret SVN 1.5 remark is to assume that it's some argument in favour of svnmerge.
Importantly, I can find any indication that properties set by svnmerge can be of direct use to SVN 1.5. I'd be happy to be proved wrong, BTW. I'm sure you're right. I don't think anyone thought differently, though. Because then, starting with svnmerge now might not be best idea -- we might as well wait for svn 1.5. What is your argument against using svnmerge.py before svn 1.5 is available?
The fact that interfaces of svnmerge.py and svn 1.5 will be different, and any instructions written for svnmerge.py will have to be rewritten, and that developers will be confused when we switch, and unless you force everybody to merge all branches right before switch to 1.5, you'll have branches that have both svnmerge.py and svn 1.5 mergeinfo, and it's doubtfull that either tool will be able to handle that.
We could probably enforce this in the pre-commit hook though, catching any use of the old svnmerge.py properties. And it's pretty likely that there will be a migration path: http://subversion.tigris.org/merge-tracking/func-spec.html#migration-and-int... "TODO: Merge meta data from svnmerge.py. Dan Berlin has written Python code to perform this migration; it needs to be made available in the tools/server-side/ area of the distribution ." -- Daniel Wallin Boost Consulting www.boost-consulting.com
on Thu Sep 06 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
David Abrahams wrote:
on Thu Sep 06 2007, Vladimir Prus <ghost-AT-cs.msu.su> wrote:
2. What made you think that SVN 1.5 will be compatible with svnmerge in any way?
What made you think Beman thought that?
Are you not going to answer that?
Unless SVN 1.5 is compatible with svnmerge in any way, then the fact that merge tracking is implemented in SVN 1.5 is rather irrelevant to our using or not using of svnmerge. It can as well be said that Perforce, svk, bzr, git, monotone and mercurial have merge tracking -- that's true, but has no bearing to anything. So the only way to interpret SVN 1.5 remark is to assume that it's some argument in favour of svnmerge.
Surely you don't think that the way you interpreted is the only way to interpret it? One conclusion one could draw is that it means "we won't have to worry about any of this after SVN 1.5 is released." I interpreted it as an incidental remark, since it was preceded with "incidentally." That usually means, "I'm just putting this information out there, draw what conclusions you will."
Importantly, I can find any indication that properties set by svnmerge can be of direct use to SVN 1.5. I'd be happy to be proved wrong, BTW.
I'm sure you're right. I don't think anyone thought differently, though.
Because then, starting with svnmerge now might not be best idea -- we might as well wait for svn 1.5.
What is your argument against using svnmerge.py before svn 1.5 is available?
The fact that interfaces of svnmerge.py and svn 1.5 will be different, and any instructions written for svnmerge.py will have to be rewritten,
That's not a big deal.
and that developers will be confused when we switch,
One can surely give people an svnmerge.py that has the same interface and works by using the svn 1.5 facilities.
and unless you force everybody to merge all branches right before switch to 1.5, you'll have branches that have both svnmerge.py and svn 1.5 mergeinfo, and it's doubtfull that either tool will be able to handle that.
Then we will be no worse off than if we had never used svnmerge.py for those branches. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
Hi! Vladimir Prus schrieb:
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree. Week later, a serious bug is found in another library. Is there a place where that bug can be fixed? Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released?
Should we have a "release-ready tree" and a "release-1-35-fixing" branch which gets all fixes merged in? The "source incompatible" change would only go into the release-ready-tree but not into the release-1-35-fixing tree (which can be tagged as release-1-35-1 when done fixing/when releasing). Frank
Frank Birbacher wrote:
Hi!
Vladimir Prus schrieb:
2. Say Boost 1.35 is released. Week later, a big source-incompatible change to some library is merged to release-ready tree. Week later, a serious bug is found in another library. Is there a place where that bug can be fixed? Release-ready tree already has source-incompatible change to other library? In other words -- from which tree is 1.35.1 going to be released?
Should we have a "release-ready tree" and a "release-1-35-fixing" branch which gets all fixes merged in? The "source incompatible" change would only go into the release-ready-tree but not into the release-1-35-fixing tree (which can be tagged as release-1-35-1 when done fixing/when releasing).
That's what I'm driving at. - Volodya
At 10:17 AM +0400 9/6/07, Vladimir Prus wrote:
Frank Birbacher wrote:
Should we have a "release-ready tree" and a "release-1-35-fixing" branch which gets all fixes merged in? The "source incompatible" change would only go into the release-ready-tree but not into the release-1-35-fixing tree (which can be tagged as release-1-35-1 when done fixing/when releasing).
That's what I'm driving at.
That was my understanding of what you were suggesting when I wrote: At 12:53 PM -0400 9/4/07, Kim Barrett wrote:
b. By default, there is no 1.35.1. [... rationale ...]
participants (18)
-
Beman Dawes -
Daniel Wallin -
David Abrahams -
Felipe Magno de Almeida -
Frank Birbacher -
Gottlob Frege -
Johan Nilsson -
John Maddock -
Kim Barrett -
Michael Caisse -
Michael Fawcett -
Michael Marcin -
Nicola Musatti -
Peter Dimov -
Rene Rivera -
Robert Ramey -
Roland Schwarz -
Vladimir Prus