A branching/tagging idea for releases
Here's an idea on how we can manage our source-control for releases: 1. When we're ready to start a new release, make a branch from the trunk with a name like release_1_??_x (e.g. "release_1_37_x") 2. Finalize what needs to be done to make that branch ship-worthy 3. Make a tag from that branch with a name like release_1_??_0 (e.g. "release_1_37_0") 4. Export that tag to a fresh directory and create the appropriate archive file to upload to SourceForge, etc. (The directory shouldn't have any source-control debris in it. Maybe this needs to be done once on each platform to ensure the best archive format and the proper line-ending markers.) 5. If bug-fixes for that release need to be done, continue to use the release_1_??_x branch (and merge the fixes back to the trunk, or vice versa) 6. Make a new tag named like release_1_??_1 and ship it as in [4] for any bug-fix releases (increase the number for subsequent bug- fixes published) 7. New stuff and substantial changes go on the trunk; publish those by going back to [1] with a release_1_(??+1)_x branch -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
Here's an idea on how we can manage our source-control for releases:
1. When we're ready to start a new release, make a branch from the trunk with a name like release_1_??_x (e.g. "release_1_37_x")
Why? What do we gain from having the release branch tagged with the version? Why branch from trunk? And there are various drawbacks, some of which where raised the last time we discussed this: * It means testing process needs to change to switch to a new branch at the start of each release. This is currently a *manual* activity which needs coordination from many people. * It makes it harder to track changes across releases since we have to backtrack through copies of loosely related source trees. * It makes it harder to stabilize the code for release since the trunk will have many more unstable changes. This is the *key* reason we switched from basing releases on trunk. And without this change a release every 3 months is impossible.
2. Finalize what needs to be done to make that branch ship-worthy 3. Make a tag from that branch with a name like release_1_??_0 (e.g. "release_1_37_0") 4. Export that tag to a fresh directory and create the appropriate archive file to upload to SourceForge, etc. (The directory shouldn't have any source-control debris in it. Maybe this needs to be done once on each platform to ensure the best archive format and the proper line-ending markers.)
We already do that.
5. If bug-fixes for that release need to be done, continue to use the release_1_??_x branch (and merge the fixes back to the trunk, or vice versa)
If a bug fix release is needed a branch can be created from the release_x_yy_z tag at any time. And it can follow the usual merge of patches and release procedures. Once that patch release is tagged and released the corresponding branch can be deleted, and the next patch for that release can start again from the appropriate tag. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
What we gain is the ability to be making bug fix releases of previous versions whilst working on the next release. With the current system there is no way of doing this simultaneously, if we want a bug fix release, which I'd suggest should happen, given the demand we've seen on the list, we need a method of doing so. As far as testing, the issue of manually updating the builders could be dealt with by having a config file available on boost.org which specifies the svn path and configuration that should be tested. Updating the release testing group is then simply a matter of updating this one file centrally. Deficiencies in the testing scripts should not be a reason to disregard a particular release procedure if the deficiency can be addressed IMO. Also with regard to stabilising trunk, I agree it won't be as easy, so instead maintain the current pratice and simply change the proposal to branch from the last stable release, thus giving the option of continuing to maintain the release on the same branch. As for tracking release history, try out some distributed version control systems, such as git or bzr, they make this kind of thing much easier, and I think that we should seriously be considering using them, this would mean we could get rid of the sandbox, since new libraries an simply be considered as branches from trunk, whih could have an enforced naming convention so it is clear they have yet to be accepted. James Sent from Google Mail for mobile On 6/29/08, Rene Rivera <grafikrobot@gmail.com> wrote:
Daryle Walker wrote:
Here's an idea on how we can manage our source-control for releases:
1. When we're ready to start a new release, make a branch from the trunk with a name like release_1_??_x (e.g. "release_1_37_x")
Why? What do we gain from having the release branch tagged with the version? Why branch from trunk? And there are various drawbacks, some of which where raised the last time we discussed this:
* It means testing process needs to change to switch to a new branch at the start of each release. This is currently a *manual* activity which needs coordination from many people.
* It makes it harder to track changes across releases since we have to backtrack through copies of loosely related source trees.
* It makes it harder to stabilize the code for release since the trunk will have many more unstable changes. This is the *key* reason we switched from basing releases on trunk. And without this change a release every 3 months is impossible.
2. Finalize what needs to be done to make that branch ship-worthy 3. Make a tag from that branch with a name like release_1_??_0 (e.g. "release_1_37_0") 4. Export that tag to a fresh directory and create the appropriate archive file to upload to SourceForge, etc. (The directory shouldn't have any source-control debris in it. Maybe this needs to be done once on each platform to ensure the best archive format and the proper line-ending markers.)
We already do that.
5. If bug-fixes for that release need to be done, continue to use the release_1_??_x branch (and merge the fixes back to the trunk, or vice versa)
If a bug fix release is needed a branch can be created from the release_x_yy_z tag at any time. And it can follow the usual merge of patches and release procedures. Once that patch release is tagged and released the corresponding branch can be deleted, and the next patch for that release can start again from the appropriate tag.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Sent from Google Mail for mobile | mobile.google.com
James Sharpe wrote:
What we gain is the ability to be making bug fix releases of previous versions whilst working on the next release. With the current system there is no way of doing this simultaneously, if we want a bug fix release, which I'd suggest should happen, given the demand we've seen on the list, we need a method of doing so.
I 100% agree with that.
As far as testing, the issue of manually updating the builders could be dealt with by having a config file available on boost.org which specifies the svn path and configuration that should be tested.
Or much more simply, you can keep a directory called "release" that simply contains an svn:externals reference to the current release revision we're testing. Of course, having testers operate on a single branch called "release," no matter how we do it, is really incompatible with the idea of testing point releases concurrently with other releases.
Updating the release testing group is then simply a matter of updating this one file centrally. Deficiencies in the testing scripts should not be a reason to disregard a particular release procedure if the deficiency can be addressed IMO.
Also with regard to stabilising trunk, I agree it won't be as easy, so instead maintain the current pratice and simply change the proposal to branch from the last stable release, thus giving the option of continuing to maintain the release on the same branch.
As for tracking release history, try out some distributed version control systems, such as git or bzr, they make this kind of thing much easier, and I think that we should seriously be considering using them,
Not gonna happen, for reasons explained in http://lists.boost.org/Archives/boost/2005/09/92862.php
this would mean we could get rid of the sandbox, since new libraries an simply be considered as branches from trunk, whih could have an enforced naming convention so it is clear they have yet to be accepted.
The sandbox is a place for people to collaborate among other things. I think svk handles all the things you want from git or bzr without forcing us to change our repo, doesn't it? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
James Sharpe wrote:
What we gain is the ability to be making bug fix releases of previous versions whilst working on the next release. With the current system there is no way of doing this simultaneously, if we want a bug fix release, which I'd suggest should happen, given the demand we've seen on the list, we need a method of doing so.
I 100% agree with that.
Some people keep saying that. But I fail to see how the current setup prevents one from doing this. The name of the branches & tags is irrelevant. They are just names! It's the content that matters. And the content is exactly the same currently. If there is a *release team* for doing a 1.35.1 release. It is their responsibility to create the branch for them to work on such a release. If it is a matter of policy that we want to add to the workload for library authors and maintain point releases on an ongoing basis. Then it is as simple as always creating a new branch for each major release at then *end* of said major release.
Of course, having testers operate on a single branch called "release," no matter how we do it, is really incompatible with the idea of testing point releases concurrently with other releases.
I don't remember where anyone said we would have only *one* tested branch. Just that it would be more work on testers to have to switch on each release cycle the branch they test. It would be the responsibility of a 1.35.1 release team to coordinate with testers, for that release, the branch to test and test resources to devote specifically to it. [stuff about version control] It is counter productive to think that a new version control system is going to solve such testing and release problems. If we can't manage the release process with the tools we have we have no hope of ever succeeding in creating a stable release process. I know, I may be sounding bitter at this point... But I'm a pragmatist at heart and trying to solve things with fresh new toys rubs me the wrong way since I've seen the tactic fail repeatedly. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Sorry to jump in here... Not being a Boost author myself makes this a little awkward, but I'd like to get my $0.02 worth in there. On Mon, Jun 30, 2008 at 11:20 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
David Abrahams wrote:
James Sharpe wrote:
What we gain is the ability to be making bug fix releases of previous versions whilst working on the next release. With the current system there is no way of doing this simultaneously, if we want a bug fix release, which I'd suggest should happen, given the demand we've seen on the list, we need a method of doing so.
I 100% agree with that.
Some people keep saying that. But I fail to see how the current setup prevents one from doing this. The name of the branches & tags is irrelevant. They are just names! It's the content that matters. And the content is exactly the same currently. If there is a *release team* for doing a 1.35.1 release. It is their responsibility to create the branch for them to work on such a release. If it is a matter of policy that we want to add to the workload for library authors and maintain point releases on an ongoing basis. Then it is as simple as always creating a new branch for each major release at then *end* of said major release.
I think the diversion here comes from the fact that only authors (or maintainers) are able to check in code to the subversion repository -- and patches that go towards a 'bugfix point release' need to go through the authors/maintainers. This is a problem of the 'not-always-stable' trunk paradigm, where major/minor development happens on the trunk which gets tested day by day. Not having the name right is a problem: say for example I as a user of the library would like to contribute a patch to a release version that addresses a particular bug *in that release*. Not knowing from which subversion branch to diff from or create a patch from *is* an issue. For example, when 1.36 comes out and we're still supporting the 1.35 release, how do I patch the 1.35 release to create a 1.35.1 release and so on for particular libraries in that release? Another is the fact that the convention for a bugfix release has not yet been solidified since the idea of a quarterly release has been proposed or put into motion. Somehow we'll need to address how the bugfix release can be done with little or no friction with the continued development of the major release(s). Bugfix releases shouldn't follow a schedule (like how the major releases do) because there may be changes that are immediate that need to be pushed as a point-release. Not only that, having this facility allows users (enterprises?) to standardize on a release and just update when that particular release does a point-release. Sometimes these users would like to stick to a release that has been tested internally by them which contains only the set of libraries in that particular release; when they find a bug, it's really unreasonable to expect them to upgrade to a new major release with potentially breaking changes to existing libraries and have to wait for a scheduled release to do this.
Of course, having testers operate on a single branch called "release," no matter how we do it, is really incompatible with the idea of testing point releases concurrently with other releases.
I don't remember where anyone said we would have only *one* tested branch. Just that it would be more work on testers to have to switch on each release cycle the branch they test. It would be the responsibility of a 1.35.1 release team to coordinate with testers, for that release, the branch to test and test resources to devote specifically to it.
So how then would a 1.35.1 release team continue to patch things up in 1.35.0 if the release branch for that release isn't named release_1_35_0? What is the process of creating a release team for a bugfix release on a major release?
[stuff about version control]
It is counter productive to think that a new version control system is going to solve such testing and release problems. If we can't manage the release process with the tools we have we have no hope of ever succeeding in creating a stable release process.
I know, I may be sounding bitter at this point... But I'm a pragmatist at heart and trying to solve things with fresh new toys rubs me the wrong way since I've seen the tactic fail repeatedly.
I agree. I think it's more about making the process clear-cut with less distractions; If somehow we set these down in a manner that makes sense and pleases the authors/maintainers more than it does 'just users' then we should be able to get to a situation where we would know precisely what to do when certain things come up -- like the need for a bugfix release. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
Dean Michael Berris wrote:
Sorry to jump in here... Not being a Boost author myself makes this a little awkward, but I'd like to get my $0.02 worth in there.
Commentary by developers who deal with software releases of any form is very much welcome in these!
On Mon, Jun 30, 2008 at 11:20 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
David Abrahams wrote:
James Sharpe wrote:
I think the diversion here comes from the fact that only authors (or maintainers) are able to check in code to the subversion repository -- and patches that go towards a 'bugfix point release' need to go through the authors/maintainers. This is a problem of the 'not-always-stable' trunk paradigm, where major/minor development happens on the trunk which gets tested day by day.
Hm, I don't see how that follows. I can see the bottleneck authors time is, and is one of my main points. But I don't see how that follows to the problem of 'not-always-stable' trunk method.
Not having the name right is a problem: say for example I as a user of the library would like to contribute a patch to a release version that addresses a particular bug *in that release*. Not knowing from which subversion branch to diff from or create a patch from *is* an issue. For example, when 1.36 comes out and we're still supporting the 1.35 release, how do I patch the 1.35 release to create a 1.35.1 release and so on for particular libraries in that release?
Sure, but those are issues of convention only. The name itself is not important, just that we decide on a name. But deciding on a name is the least important aspect. The only option users have at this time is to diff from the tags/release/Boost_x_y_z (or from the archives directly).
So how then would a 1.35.1 release team continue to patch things up in 1.35.0 if the release branch for that release isn't named release_1_35_0?
It could be named release_1_35, or release/Boost_1_35, etc. Hence the name is not important, just that it's agreed upon.
What is the process of creating a release team for a bugfix release on a major release?
I would think the same as it is now for a regular release. Someone volunteers to be the release manager. And they ask for volunteers to help in the release, assuming they need help. And then they go through the same release process as for a regular release, just on a different branch and schedule. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Mon, Jun 30, 2008 at 11:15 PM, Rene Rivera <grafikrobot@gmail.com> wrote:
Dean Michael Berris wrote:
Sorry to jump in here... Not being a Boost author myself makes this a little awkward, but I'd like to get my $0.02 worth in there.
Commentary by developers who deal with software releases of any form is very much welcome in these!
Thanks. :)
On Mon, Jun 30, 2008 at 11:20 AM, Rene Rivera <grafikrobot@gmail.com> wrote:
David Abrahams wrote:
James Sharpe wrote:
I think the diversion here comes from the fact that only authors (or maintainers) are able to check in code to the subversion repository -- and patches that go towards a 'bugfix point release' need to go through the authors/maintainers. This is a problem of the 'not-always-stable' trunk paradigm, where major/minor development happens on the trunk which gets tested day by day.
Hm, I don't see how that follows. I can see the bottleneck authors time is, and is one of my main points. But I don't see how that follows to the problem of 'not-always-stable' trunk method.
The problem the not-always-stable trunk method brings in this situation is where a fix that has to be made/applied to a library that's already been released either goes first into trunk (because trunk is not intended to be stable at all) then needs to wait for the next release. Since the trunk is not always stable, you then encounter the problem of having to maintain a different version of the libraries in different branches -- a release 1.35, 1.34, 1.35.1, 1.36, etc. -- In case the trunk was always stable, then fixes that get applied to a bugfix release can be merged into the trunk; then further development of the library can happen in a private branch. The unstable trunk also disallows the release manager(s) from simply cutting a branch from trunk every-time a new release is to be made. This exacerbates the problem because now instead of fixes that go into the trunk that's intended to fix an issue in the release branch _for the sole purpose of fixing bugs in that release branch_ will have to be manually merged into the new release branch that was rooted on the previous release version of the library. So now you're faced with two issues: 1. The 'time-to-market' or 'time-to-release' of a fix that's intended to address an issue in a release version gets longer and gets packaged into a new major release. 2. The many versions of the library in supported major release version and the many bug fixes that need to be tracked accordingly. I'm not suggesting that we should start following the 'always-stable-trunk' method -- where we have a private branch named 'unstable' on which all breaking changes on a daily basis happen, and on to which major changes in libraries have to be merged into before being merged into the trunk after full regression testing. I'm rather citing the difficulty of having authors working on private branches then having to merge directly to trunk, and the release managers having to cut branches from the last stable release instead of a stable trunk and merging changes from the trunk done manually.
Not having the name right is a problem: say for example I as a user of the library would like to contribute a patch to a release version that addresses a particular bug *in that release*. Not knowing from which subversion branch to diff from or create a patch from *is* an issue. For example, when 1.36 comes out and we're still supporting the 1.35 release, how do I patch the 1.35 release to create a 1.35.1 release and so on for particular libraries in that release?
Sure, but those are issues of convention only. The name itself is not important, just that we decide on a name. But deciding on a name is the least important aspect. The only option users have at this time is to diff from the tags/release/Boost_x_y_z (or from the archives directly).
So how then would a 1.35.1 release team continue to patch things up in 1.35.0 if the release branch for that release isn't named release_1_35_0?
It could be named release_1_35, or release/Boost_1_35, etc. Hence the name is not important, just that it's agreed upon.
Okay. I guess then we just have to make that convention more 'formal' then?
What is the process of creating a release team for a bugfix release on a major release?
I would think the same as it is now for a regular release. Someone volunteers to be the release manager. And they ask for volunteers to help in the release, assuming they need help. And then they go through the same release process as for a regular release, just on a different branch and schedule.
Okay. -- Dean Michael C. Berris Software Engineer, Friendster, Inc.
Rene Rivera wrote:
David Abrahams wrote:
James Sharpe wrote:
What we gain is the ability to be making bug fix releases of previous versions whilst working on the next release. With the current system there is no way of doing this simultaneously, if we want a bug fix release, which I'd suggest should happen, given the demand we've seen on the list, we need a method of doing so.
I 100% agree with that.
Some people keep saying that. But I fail to see how the current setup prevents one from doing this. The name of the branches & tags is irrelevant. They are just names! It's the content that matters.
Exactly.
And the content is exactly the same currently.
The same as what?
If there is a *release team* for doing a 1.35.1 release. It is their responsibility to create the branch for them to work on such a release. If it is a matter of policy that we want to add to the workload for library authors and maintain point releases on an ongoing basis.
Surely you don't think the purpose of doing a point release is to add to the workload for library authors? The point is to serve users who aren't prepared to accept a new major revision with all the incompatibilities that may entail, but who need bugfixes.
Then it is as simple as always creating a new branch for each major release at then *end* of said major release.
That could work too. As long as there's a way to handle it, that's fine with me. As it stands today, when a library author finds a bug that ought to be fixed in the next point release (should we decide to make one) there's no place for him to check the fix in that will guarantee that it goes into the point release.
Of course, having testers operate on a single branch called "release," no matter how we do it, is really incompatible with the idea of testing point releases concurrently with other releases.
I don't remember where anyone said we would have only *one* tested branch. Just that it would be more work on testers to have to switch on each release cycle the branch they test.
If you assume we're switching on every release cycle, people will be used to doing it, or there's at least a good chance it will be automated (c'mon, that's _trivial_ by comparison to many of the things we do for testing!) whereas if testers have to manually switch in order to test a point release there will be mayhem by comparison.
It would be the responsibility of a 1.35.1 release team to coordinate with testers, for that release, the branch to test and test resources to devote specifically to it.
Sounds like a plan without a plan.
[stuff about version control]
It is counter productive to think that a new version control system is going to solve such testing and release problems. If we can't manage the release process with the tools we have we have no hope of ever succeeding in creating a stable release process.
I know, I may be sounding bitter at this point... But I'm a pragmatist at heart and trying to solve things with fresh new toys rubs me the wrong way since I've seen the tactic fail repeatedly.
What gave you the idea that I was suggesting we use a new VC system? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
Rene Rivera wrote:
David Abrahams wrote:
James Sharpe wrote:
What we gain is the ability to be making bug fix releases of previous versions whilst working on the next release. With the current system there is no way of doing this simultaneously, if we want a bug fix release, which I'd suggest should happen, given the demand we've seen on the list, we need a method of doing so. I 100% agree with that. Some people keep saying that. But I fail to see how the current setup prevents one from doing this. The name of the branches & tags is irrelevant. They are just names! It's the content that matters.
Exactly.
And the content is exactly the same currently.
The same as what?
The same as if the release branch where named release_1_36_0. Or if you have branches "release", "release_1_35", "release_1_35_0", "release/1_35", "release/1_36", etc.
Surely you don't think the purpose of doing a point release is to add to the workload for library authors?
Of course not. I'm just stating the fact that it will increase workload. I'm not even saying that it's not worth it. Since I believe it is worth it. But I'm skeptical that we have the workload to spare.
Then it is as simple as always creating a new branch for each major release at then *end* of said major release.
That could work too. As long as there's a way to handle it, that's fine with me. As it stands today, when a library author finds a bug that ought to be fixed in the next point release (should we decide to make one) there's no place for him to check the fix in that will guarantee that it goes into the point release.
Well, here's what I worry about... We set up point branches, say release_1_36 for this example. Authors put in fixes to release_1_36. No one ever volunteers to manage a 1.36.1 release. We end up with wasted work, and less than happy authors. Although users will be happy since they can get a fixed 1.36.x from SVN at any time.
Of course, having testers operate on a single branch called "release," no matter how we do it, is really incompatible with the idea of testing point releases concurrently with other releases. I don't remember where anyone said we would have only *one* tested branch. Just that it would be more work on testers to have to switch on each release cycle the branch they test.
If you assume we're switching on every release cycle, people will be used to doing it, or there's at least a good chance it will be automated (c'mon, that's _trivial_ by comparison to many of the things we do for testing!) whereas if testers have to manually switch in order to test a point release there will be mayhem by comparison.
It's not really the act of switching the scripts to new branches that is the hard work, since that is bone simple at this point. It's the coordination, through email, that is painful. Testers are not the kind of people who have time to respond immediately nor act immediately. I say that from experience of getting testers to do things like clear out results. So if you want to coordinate a split in testing resources one has to plan for one to two weeks of back and forth.
It would be the responsibility of a 1.35.1 release team to coordinate with testers, for that release, the branch to test and test resources to devote specifically to it.
Sounds like a plan without a plan.
It's the same plan we have right now. Beman decides which platforms are release platforms and the testers and I decided whom will make their scripts test trunk or release.
[stuff about version control]
It is counter productive to think that a new version control system is going to solve such testing and release problems. If we can't manage the release process with the tools we have we have no hope of ever succeeding in creating a stable release process.
I know, I may be sounding bitter at this point... But I'm a pragmatist at heart and trying to solve things with fresh new toys rubs me the wrong way since I've seen the tactic fail repeatedly.
What gave you the idea that I was suggesting we use a new VC system?
I wasn't directing this at you. I was responding to the general pattern. After all the OP did suggest switching VC systems. But my comment is not just about VC systems. It's about all the tools. For example the various discussions about switching the build system and phrasing it as if switching the build system will solve testing problems. When in reality the build system has almost nothing to do with the current testing problems we have. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
On Jun 30, 2008, at 10:33 AM, Rene Rivera wrote:
David Abrahams wrote:
Rene Rivera wrote:
[SNIP]
[stuff about version control]
It is counter productive to think that a new version control system is going to solve such testing and release problems. If we can't manage the release process with the tools we have we have no hope of ever succeeding in creating a stable release process.
I know, I may be sounding bitter at this point... But I'm a pragmatist at heart and trying to solve things with fresh new toys rubs me the wrong way since I've seen the tactic fail repeatedly. What gave you the idea that I was suggesting we use a new VC system?
I wasn't directing this at you. I was responding to the general pattern. After all the OP did suggest switching VC systems. But my comment is not just about VC systems. It's about all the tools. For example the various discussions about switching the build system and phrasing it as if switching the build system will solve testing problems. When in reality the build system has almost nothing to do with the current testing problems we have.
James Sharpe said that, not the OP (which is me). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
2008/7/2 Daryle Walker <darylew@hotmail.com>:
I wasn't directing this at you. I was responding to the general pattern. After all the OP did suggest switching VC systems. But my comment is not just about VC systems. It's about all the tools. For example the various discussions about switching the build system and phrasing it as if switching the build system will solve testing problems. When in reality the build system has almost nothing to do with the current testing problems we have.
James Sharpe said that, not the OP (which is me).
And I only suggested it in response to the argument that frequently changing branches makes it difficult to track changes between releases, whereas this is only really true with centralized VCS systems; I argued that a DVCS makes this point not valid anymore; in particular I had in mind the gitk tool for git which enables you to visualise the merge history of the release, thus making tracking changes very easy.
David Abrahams wrote:
Rene Rivera wrote:
David Abrahams wrote:
James Sharpe wrote:
What we gain is the ability to be making bug fix releases of previous versions whilst working on the next release. With the current system there is no way of doing this simultaneously, if we want a bug fix release, which I'd suggest should happen, given the demand we've seen on the list, we need a method of doing so. I 100% agree with that. Some people keep saying that. But I fail to see how the current setup prevents one from doing this. The name of the branches & tags is irrelevant. They are just names! It's the content that matters.
Exactly.
And the content is exactly the same currently.
The same as what?
If there is a *release team* for doing a 1.35.1 release. It is their responsibility to create the branch for them to work on such a release. If it is a matter of policy that we want to add to the workload for library authors and maintain point releases on an ongoing basis.
Surely you don't think the purpose of doing a point release is to add to the workload for library authors? The point is to serve users who aren't prepared to accept a new major revision with all the incompatibilities that may entail, but who need bugfixes.
Then it is as simple as always creating a new branch for each major release at then *end* of said major release.
That could work too. As long as there's a way to handle it, that's fine with me. As it stands today, when a library author finds a bug that ought to be fixed in the next point release (should we decide to make one) there's no place for him to check the fix in that will guarantee that it goes into the point release.
What's wrong with branches/release as the location of the point release? Presumably developers are merging fixes there anyhow, it is being tested, inspected, and release files being built on a daily basis.
Of course, having testers operate on a single branch called "release," no matter how we do it, is really incompatible with the idea of testing point releases concurrently with other releases. I don't remember where anyone said we would have only *one* tested branch. Just that it would be more work on testers to have to switch on each release cycle the branch they test.
That just doesn't work in practice. Having to beg, plead, and pester testers to switch isn't a workable solution. --Beman
Beman Dawes wrote:
David Abrahams wrote:
Rene Rivera wrote:
David Abrahams wrote:
James Sharpe wrote:
What we gain is the ability to be making bug fix releases of previous versions whilst working on the next release. With the current system there is no way of doing this simultaneously, if we want a bug fix release, which I'd suggest should happen, given the demand we've seen on the list, we need a method of doing so. I 100% agree with that. Some people keep saying that. But I fail to see how the current setup prevents one from doing this. The name of the branches & tags is irrelevant. They are just names! It's the content that matters.
Exactly.
And the content is exactly the same currently.
The same as what?
If there is a *release team* for doing a 1.35.1 release. It is their responsibility to create the branch for them to work on such a release. If it is a matter of policy that we want to add to the workload for library authors and maintain point releases on an ongoing basis.
Surely you don't think the purpose of doing a point release is to add to the workload for library authors? The point is to serve users who aren't prepared to accept a new major revision with all the incompatibilities that may entail, but who need bugfixes.
Then it is as simple as always creating a new branch for each major release at then *end* of said major release.
That could work too. As long as there's a way to handle it, that's fine with me. As it stands today, when a library author finds a bug that ought to be fixed in the next point release (should we decide to make one) there's no place for him to check the fix in that will guarantee that it goes into the point release.
What's wrong with branches/release as the location of the point release? Presumably developers are merging fixes there anyhow, it is being tested, inspected, and release files being built on a daily basis.
If you're suggesting that we consider some snapshot of branches/release to be a point release of each officially released version, then that won't fly at all. One of the main reasons people want a point release is so they can be sure they're accepting only minimal changes to the release they're working on: just bug fixes and that's _it_.
Of course, having testers operate on a single branch called "release," no matter how we do it, is really incompatible with the idea of testing point releases concurrently with other releases. I don't remember where anyone said we would have only *one* tested branch. Just that it would be more work on testers to have to switch on each release cycle the branch they test.
That just doesn't work in practice. Having to beg, plead, and pester testers to switch isn't a workable solution.
But you don't need to, as has been pointed out many times. Just use an svn:externals to cause a copy of the current release branch to be found under the same name. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
[I haven't responded because you've changed my mind and I mostly agree with you. I didn't think that others will run with the ball I threw out there.] On Jun 29, 2008, at 5:08 PM, Rene Rivera wrote:
Daryle Walker wrote:
Here's an idea on how we can manage our source-control for releases: 1. When we're ready to start a new release, make a branch from the trunk with a name like release_1_??_x (e.g. "release_1_37_x")
Why? What do we gain from having the release branch tagged with the version? Why branch from trunk? And there are various drawbacks, some of which where raised the last time we discussed this: [TRUNCATE stuff I (now) agree with and/or about to reiterate]
Are you thinking about keeping the same branch name no matter which release (1.36 v. 1.37 v. 1.38 etc.) is being prepared? I think that's what you're saying; and that plan means that testers just park on that branch and it'll get revised after each release cycle, right? (The testers have to follow testing announcements or "cron" their working copy for updates.) But isn't that branch going to be temporary, that we'll: 1. Tag the cut-off point on the trunk that the release will be based on 2. Make a branch named "release" based off the tag in [1] 3. Do any minimal fixes to make the branch stable 4. Tag that branch with the release number 1.??.0 and remerge to the trunk (4a. This allows post-release material to still be added to trunk) (4b. Export this new tag to create the release archives) 5. When doing a bug release, do steps [1]-[4], but base [1] off of the "1.??.(bug-1)" tag of the previous release of the line So most of the time the "release" branch won't exist. I'm not a subversion expert, so I wonder if the tester's working copies will choke during this period? Or are we going to make the "release" branch shadow the trunk when we're not preparing a release, so the working copy isn't a dangling reference? Note that I'm assuming that the trunk is generally always in a ready-to-go state, which I think is a good idea. Where else would you branch from if not from the trunk? And if you were going to run the release directly from the trunk instead, wouldn't that block people from making post-1.?? changes/additions? [I just jumped back in, so I haven't yet gotten around to previous rounds of this discussion.] From what I've seen on this thread so far, I think we still wondering how bug-fix releases should be done. Here's an idea: 1. Once a month (or so), a release manager will pick minor problems to be packaged in a bug release. All of said problems _must_ be listed in our Trac system. Each issue should be as focused as possible. We can list the applicable issues together under a Trac milestone entry for the bug release. 2. The fixes for each issue should also be as focused as possible, to minimize the diff size and/or conflict-resolution pain. I _highly_ recommend that applicable fixes must already have been saved in the trunk between releases (or nearly so), so we don't have to worry about the time-crunch of getting the fixes done. (We doing one or two of these between each three-month regular release, remember!) I think Trac milestone system will help track the fixes. 3. The temporary "release" branch will be made, this time based on the "release_1_??_(bug-1)" tag (instead of the trunk). The change- sets from each resolved issue will be applied to the branch. Then we test & touch up the branch for stability, tag it, and remerge it to the trunk. (The release manager would export the new bug-fix tag to create the release archives.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
participants (6)
-
Beman Dawes -
Daryle Walker -
David Abrahams -
Dean Michael Berris -
James Sharpe -
Rene Rivera