David Abrahams wrote:
Rene Rivera 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
David Abrahams wrote: 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