[1.37.0] branches/release open for merges
******************************************************************** branches/release is open for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. ******************************************************************** In other words, merging changes *does not* need any permission from a release manager! I.e. just do it! New libraries do need permission before merging. Links relating to this release: * Google Calendar with the release schedule: <http://www.boost.org/community/index.html>. * Release schedule explanation: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>. * Release practices for everyone to follow at: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>. Bookmark, memorize, carve, or whatever else you need to do to remember this information ;-) --Beman Dawes, Rene Rivera, Daniel James
Beman Dawes wrote:
******************************************************************** branches/release is open for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. ********************************************************************
Hi Beman, Rene, Daniel, I know I should already know this, but I was completely lost in the Wiki pages. Perhaps just the stifling heat we have here. Well, I made several changes related to dynamic_bitset, in trunk, and I thought they would be (now) in the release 1.37 branch. They aren't. So, where does the release branch originate from? Thanks, -- Genny
Gennaro Prota wrote:
Beman Dawes wrote:
******************************************************************** branches/release is open for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. ********************************************************************
Hi Beman, Rene, Daniel,
I know I should already know this, but I was completely lost in the Wiki pages. Perhaps just the stifling heat we have here. Well, I made several changes related to dynamic_bitset, in trunk, and I thought they would be (now) in the release 1.37 branch. They aren't. So, where does the release branch originate from?
It's always from the previous release. -- -- 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 Aug 19, 2008, at 8:34 AM, Rene Rivera wrote:
Gennaro Prota wrote:
******************************************************************** branches/release is open for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. ******************************************************************** Hi Beman, Rene, Daniel, I know I should already know this, but I was completely lost in
Beman Dawes wrote: the Wiki pages. Perhaps just the stifling heat we have here. Well, I made several changes related to dynamic_bitset, in trunk, and I thought they would be (now) in the release 1.37 branch. They aren't. So, where does the release branch originate from?
It's always from the previous release.
Is this a good thing? Wouldn't this mean that the releases will diverge from the trunk, increasingly so after each release? I feel that would be _very_ bad. Is there some sort of merging going on between the trunk and release (in either direction, or both)? We don't want fixes and new libraries on the trunk being missed for release. Shouldn't the final form of the release workspace be merged back into the trunk (and then the branch [but not tag] deleted), and the next version's workspace branched from the merged trunk? -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
Daryle Walker wrote:
On Aug 19, 2008, at 8:34 AM, Rene Rivera wrote:
Gennaro Prota wrote: [...]
where does the release branch originate from?
It's always from the previous release.
Is this a good thing?
Not to me. I imagine that, in a time in which I wasn't following the list, there have been long discussions which led to the current state of affairs. So, it may be clear to everyone except me. What I know for sure is that this requires *a lot* of work every time you make a modification; and either a lot of memory on your part, or a file where you note the inter-release changes down, detailedly (I certainly don't trust merging a whole directory (or multiple ones) blindly: I want to see exactly what gets merged; and, to do this, I have to keep a list of what changes I made). With such an approach, I'd expect more problems due to naive merges than problems due to an unstable trunk version being used as a branch point. My $1.7 cent -- Genny
Gennaro Prota wrote:
Daryle Walker wrote:
On Aug 19, 2008, at 8:34 AM, Rene Rivera wrote:
Gennaro Prota wrote: [...]
where does the release branch originate from?
It's always from the previous release.
Is this a good thing?
Not to me. I imagine that, in a time in which I wasn't following the list, there have been long discussions which led to the current state of affairs. So, it may be clear to everyone except me. What I know for sure is that this requires *a lot* of work every time you make a modification; and either a lot of memory on your part, or a file where you note the inter-release changes down, detailedly (I certainly don't trust merging a whole directory (or multiple ones) blindly: I want to see exactly what gets merged; and, to do this, I have to keep a list of what changes I made). With such an approach, I'd expect more problems due to naive merges than problems due to an unstable trunk version being used as a branch point.
Whoa! None of that has to be done manually. Subversion provides plenty of tools to manage differences between trunk and branches/release. There are several ways to go about merging. One procedure is to switch your working copy to branches/release, merge changes from branches/release to trunk into your working copy, and then view the differences. The only thing even remotely tricky is to remember the diff to be merged is from branches/release to trunk, not the other way around. If all changes are to be merge, you are ready to commit. But if only some changes are to be merged, or just to be sure, I view the diff between the merged but not yet committed working copy and the repository. On Windows, I prefer a GUI approach, so use TortoiseSVN configured with Beyond Compare as the diff viewer and editor. If there are specific changes I don't want moved to branches/release, it is easy to revert (select, click the <- button) those specific changes. Save. Commit. --Beman
Beman Dawes wrote:
Gennaro Prota wrote:
Daryle Walker wrote:
On Aug 19, 2008, at 8:34 AM, Rene Rivera wrote:
Gennaro Prota wrote: [...]
where does the release branch originate from?
It's always from the previous release.
Is this a good thing?
Not to me. I imagine that, in a time in which I wasn't following the list, there have been long discussions which led to the current state of affairs. So, it may be clear to everyone except me. What I know for sure is that this requires *a lot* of work every time you make a modification; and either a lot of memory on your part, or a file where you note the inter-release changes down, detailedly (I certainly don't trust merging a whole directory (or multiple ones) blindly: I want to see exactly what gets merged; and, to do this, I have to keep a list of what changes I made). With such an approach, I'd expect more problems due to naive merges than problems due to an unstable trunk version being used as a branch point.
Whoa! None of that has to be done manually. Subversion provides plenty of tools to manage differences between trunk and branches/release.
There are several ways to go about merging. One procedure is to switch your working copy to branches/release, merge changes from branches/release to trunk into your working copy, and then view the differences. The only thing even remotely tricky is to remember the diff to be merged is from branches/release to trunk, not the other way around.
If all changes are to be merge, you are ready to commit. But if only some changes are to be merged, or just to be sure, I view the diff between the merged but not yet committed working copy and the repository. I'm still not sure I completely understand, sorry. I'm typically only working on trunk, unless I have last-minute fixes that need to be applied, in which case I apply them to trunk, as well as the (current) release branch. Hopefully this is all I have to care about. Is this indeed so ?
If you start working on the 37 release, using the 1_36 branch, who is in charge of merging the new stuff that went into trunk but isn't present in the 1_36 branch ? I sure hope it's not me. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld:
If you start working on the 37 release, using the 1_36 branch, who is in charge of merging the new stuff that went into trunk but isn't present in the 1_36 branch ? I sure hope it's not me.
It's you, sorry. In addition, there are no separate 1_36 and 1_37 branches, there is only a single 'release' branch that is periodically released as 1.36, 1.37 and so on. In practice this means that there are two "trunks" that need to be maintained in parallel and kept from desync-ing; if/when they deviate past the point of no return, there will be much suffering. One reasonable procedure would be to experiment on branches, integrate into trunk, wait for the tests, then immediately merge the same change into release. In other words, keep trunk and release synchronized at all times, with release only lagging by a test cycle or two. Another would be to move everything pertaining to libfoo into boost/foo/ and libs/foo/. I'm so looking forward to bringing smart_ptr and bind into compliance. Well, maybe not. :-)
Peter Dimov wrote:
Stefan Seefeld:
If you start working on the 37 release, using the 1_36 branch, who is in charge of merging the new stuff that went into trunk but isn't present in the 1_36 branch ? I sure hope it's not me.
It's you, sorry.
Ouch.
In addition, there are no separate 1_36 and 1_37 branches, there is only a single 'release' branch that is periodically released as 1.36, 1.37 and so on. It seems I have never understand neither the how nor the why. Ah well.
In practice this means that there are two "trunks" that need to be maintained in parallel and kept from desync-ing; if/when they deviate past the point of no return, there will be much suffering.
In fact, what is trunk good for ? My current understanding of the situation suggests to me that I should just never commit anything to trunk, but the current 'release branch'. That way I only have to care about a single check-in (that's what I'm used to on other projects). Of course, as soon as a significant amount of people do that, trunk becomes useless. I see a couple of other issues with this procedure as I understand it (now), but this is not the point and place to discuss them. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
In fact, what is trunk good for ?
My current understanding of the situation suggests to me that I should just never commit anything to trunk, but the current 'release branch'.
Noooo!!
That way I only have to care about a single check-in (that's what I'm used to on other projects). Of course, as soon as a significant amount of people do that, trunk becomes useless. I see a couple of other issues with this procedure as I understand it (now), but this is not the point and place to discuss them.
There should never *ever* be any changes applied to the release branch that have not been applied and tested on Trunk *first*. In short: commit to trunk, wait for the test results to cycle at least once, and when you're sure that the code is stable and release ready on all supported platforms, only then merge to the release branch. The expectation is that most people will merge to the release branch only periodically, when there are a number of release-ready changes pending. John.
John Maddock wrote:
Stefan Seefeld wrote:
In fact, what is trunk good for ?
My current understanding of the situation suggests to me that I should just never commit anything to trunk, but the current 'release branch'.
Noooo!!
That way I only have to care about a single check-in (that's what I'm used to on other projects). Of course, as soon as a significant amount of people do that, trunk becomes useless. I see a couple of other issues with this procedure as I understand it (now), but this is not the point and place to discuss them.
There should never *ever* be any changes applied to the release branch that have not been applied and tested on Trunk *first*.
In short: commit to trunk, wait for the test results to cycle at least once,
On all platforms, including those that are not release platforms? Say somebody commits a revision 1234567 to trunk; if there an easy way to tell if it's OK to merge trunk state, as of revision 1234567 to the release branch? Preferrably, without manually comparing the list of release compilers with the list of compilers used for trunk testing and comparing revision numbers for each? - Volodya
Vladimir Prus wrote:
On all platforms, including those that are not release platforms? Say somebody commits a revision 1234567 to trunk; if there an easy way to tell if it's OK to merge trunk state, as of revision 1234567 to the release branch? Preferrably, without manually comparing the list of release compilers with the list of compilers used for trunk testing and comparing revision numbers for each?
So the question is "When is it OK to merge from the trunk into release?" I see a couple of different possible answers: a) When the library is as good as the author can make it b) When the library is better in at least one way than the current release and in no way worse. That is when releasing the changes will result in an improvement for someone and cause no harm to anyone. c) When tests pass on "release compilers" For a new library I would prefer a). For an improvement/bug fix to and existing library, I would prefer b). Personally, I would never prefer c) since it opens up a whole issue of what it means to be "release platform" which I don't think is a very useful concept in this context. Robert Ramey
Robert Ramey wrote:
Vladimir Prus wrote:
On all platforms, including those that are not release platforms? Say somebody commits a revision 1234567 to trunk; if there an easy way to tell if it's OK to merge trunk state, as of revision 1234567 to the release branch? Preferrably, without manually comparing the list of release compilers with the list of compilers used for trunk testing and comparing revision numbers for each?
So the question is "When is it OK to merge from the trunk into release?"
I see a couple of different possible answers:
a) When the library is as good as the author can make it
b) When the library is better in at least one way than the current release and in no way worse. That is when releasing the changes will result in an improvement for someone and cause no harm to anyone.
c) When tests pass on "release compilers"
For a new library I would prefer a). For an improvement/bug fix to and existing library, I would prefer b). Personally, I would never prefer c) since it opens up a whole issue of what it means to be "release platform" which I don't think is a very useful concept in this context.
Well, (a) is non-verifiable, and (b) is hard to achieve (e.g. you cannot check "in no way worse" for toolsets that are not tested, and "no way worse" might include non-testable things. So, we only have test results for trunk and release branch, and have to decide of merge from trunk and release branch is OK. All I'm asking is whether, assuming I'm otherwise willing to do the merge, if I can arrive at this "OK/not OK" decision without any manual investigation and comparison of test results? - Volodya
Vladimir Prus wrote:
Well, (a) is non-verifiable, and (b) is hard to achieve (e.g. you cannot check "in no way worse" for toolsets that are not tested, and "no way worse" might include non-testable things.
OK I'll rephase a) When the library is as good as the author THINKS he can make it b) This is easy - when the number of regressions is less than before the change or there is an improvement and no new regressions. re b) Naturally, there can be no regression for a compiler that has never been tested.
So, we only have test results for trunk and release branch, and have to decide of merge from trunk and release branch is OK. All I'm asking is whether, assuming I'm otherwise willing to do the merge, if I can arrive at this "OK/not OK" decision without any manual investigation and comparison of test results?
Hmmm - b) requires some manual investigation / comparison of test results. So I would still recommend b) for improvements and a) for new libraries. Robert Ramey
Robert Ramey wrote:
So the question is "When is it OK to merge from the trunk into release?"
I see a couple of different possible answers:
a) When the library is as good as the author can make it
b) When the library is better in at least one way than the current release and in no way worse. That is when releasing the changes will result in an improvement for someone and cause no harm to anyone.
c) When tests pass on "release compilers"
For a new library I would prefer a). For an improvement/bug fix to and existing library, I would prefer b). Personally, I would never prefer c) since it opens up a whole issue of what it means to be "release platform" which I don't think is a very useful concept in this context.
Or treat (c) as a prerequisite to (a) and (b) ? John.
John Maddock wrote:
In short: commit to trunk, wait for the test results to cycle at least once, and when you're sure that the code is stable and release ready on all supported platforms, only then merge to the release branch.
This description of 'trunk' sounds more like it should be called 'sandbox' to me. May be that would indeed be a good idea to clarify the process you are promoting.
The expectation is that most people will merge to the release branch only periodically, when there are a number of release-ready changes pending.
As usual, this may get quite complex if changesets are interdependent. I.e., it may be that one patch that went into trunk only works because of another patch in trunk, but would fail in release without the other there applied first. In any case, thanks for the clarification ! Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
John Maddock wrote:
In short: commit to trunk, wait for the test results to cycle at least once, and when you're sure that the code is stable and release ready on all supported platforms, only then merge to the release branch.
This description of 'trunk' sounds more like it should be called 'sandbox' to me. May be that would indeed be a good idea to clarify the process you are promoting.
Sandboxes are for experimental changes, Trunk is for stable changes that you have tested locally to the best of your ability, but which needs the full regression tests to be run before it's considered "release ready". In fact, the *aim* is to keep Trunk release ready at all times, the trouble is we've found that not to work in practice, as even with the best will in the world unexpected breakages do occur. Separating Trunk and release branch is intended to minimise this kind of unintentional (or down right sloppy!) breakage.
The expectation is that most people will merge to the release branch only periodically, when there are a number of release-ready changes pending.
As usual, this may get quite complex if changesets are interdependent. I.e., it may be that one patch that went into trunk only works because of another patch in trunk, but would fail in release without the other there applied first.
It does, been there, experienced that already :-( Actually while it cost me a bit of extra time, it wasn't too bad after all, HTH, John.
Stefan Seefeld wrote:
The expectation is that most people will merge to the release branch only periodically, when there are a number of release-ready changes pending.
As usual, this may get quite complex if changesets are interdependent. I.e., it may be that one patch that went into trunk only works because of another patch in trunk, but would fail in release without the other there applied first.
If this shows up when a merge is made of a library into the release ready branch it should be considered a bug as it must be a break in an interface contract. If this is an obtacle to making this system work - then there is no system that can work. Robert Ramey
Robert Ramey wrote:
Stefan Seefeld wrote:
The expectation is that most people will merge to the release branch only periodically, when there are a number of release-ready changes pending.
As usual, this may get quite complex if changesets are interdependent. I.e., it may be that one patch that went into trunk only works because of another patch in trunk, but would fail in release without the other there applied first.
If this shows up when a merge is made of a library into the release ready branch it should be considered a bug as it must be a break in an interface contract.
I fail to understand what you are saying. As far as I know, there are no 'interface contracts' on trunk. And, adding a new feature in patch A, which a subsequent patch B relies on is certainly a possibility, if not even likely. The point I'm trying to make is that, as far as I can see, there is no dependency tracking between changesets, so it may be hard to tell whether a merge of any changeset from trunk to the release branch will be self-contained, or rely on another merge being done first. Anyways, my main point remains this: The way you treat the 'release branch' is how other projects use 'trunk' for, while what you name 'trunk' is more of a 'sandbox' elsewhere. Only that boost doesn't have what other projects call release branches, so you are unable to do bugfix-only releases. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
If this shows up when a merge is made of a library into the release ready branch it should be considered a bug as it must be a break in an interface contract.
I fail to understand what you are saying. As far as I know, there are no 'interface contracts' on trunk. And, adding a new feature in patch A, which a subsequent patch B relies on is certainly a possibility, if not even likely.
It is not an attribute of the branch but of the library. The "interface contract" is that the library does what it's documentation says it does.
The point I'm trying to make is that, as far as I can see, there is no dependency tracking between changesets, so it may be hard to tell whether a merge of any changeset from trunk to the release branch will be self-contained, or rely on another merge being done first.
There should be no direct dependency between changesets. If there is - its a bug. Library A should depend upon, and only upon, the documented interface of Library B. If merging B into the release branch breaks library A - then either B as changed its interface so it doesn't match the documentation or A wasn't incompliance with the documentation. Either way its a bug.
Anyways, my main point remains this:
The way you treat the 'release branch' is how other projects use 'trunk' for, while what you name 'trunk' is more of a 'sandbox' elsewhere.
Nope. The trunk is where libraries are tested before being merged into the trunk. A "sandbox" would be a separate branch where experiments are conducted. For this one doesn't need all the testing on various platforms - yet. When the "experiment" is ready for that, then it gets merged into the trunk.
Only that boost doesn't have what other projects call release branches, so you are unable to do bugfix-only releases.
The release branch is almost always ready for release. If a user needs a bug fix or "hot patch" - all he has to do is download it from there. He can either download the whole thing or just the library he's interested in. Robert Ramey
Robert Ramey wrote:
Stefan Seefeld wrote:
If this shows up when a merge is made of a library into the release ready branch it should be considered a bug as it must be a break in an interface contract.
I fail to understand what you are saying. As far as I know, there are no 'interface contracts' on trunk. And, adding a new feature in patch A, which a subsequent patch B relies on is certainly a possibility, if not even likely.
It is not an attribute of the branch but of the library. The "interface contract" is that the library does what it's documentation says it does.
So what ? I recently added a new feature to the boost.python library, in a patch I committed to trunk. What if Joe Random tomorrow submits a separate patch, making use of this feature ? What, then, if the two changesets are (separately !) considered to be merged into some other branch ?
The point I'm trying to make is that, as far as I can see, there is no dependency tracking between changesets, so it may be hard to tell whether a merge of any changeset from trunk to the release branch will be self-contained, or rely on another merge being done first.
There should be no direct dependency between changesets. If there is - its a bug.
Huh ?
Library A should depend upon, and only upon, the documented interface of Library B. If merging B into the release branch breaks library A - then either B as changed its interface so it doesn't match the documentation or A wasn't incompliance with the documentation. Either way its a bug.
First, I'm not necessarily talking about dependencies between different libraries, I'm talking about dependencies between patches / changesets, no matter what source they are applied against. Second, the issue I'm talking about has nothing to do with whether the change is documented or not. The dependency between the changesets needs to be tracked, somehow. Third, even if something (library or not) changes in trunk, and something other is added relying on this change. That doesn't yet answer how those two changes percolate into any release branch.
Anyways, my main point remains this:
The way you treat the 'release branch' is how other projects use 'trunk' for, while what you name 'trunk' is more of a 'sandbox' elsewhere.
Nope. The trunk is where libraries are tested before being merged into the trunk.
A "sandbox" would be a separate branch where experiments are conducted. For this one doesn't need all the testing on various platforms - yet. When the "experiment" is ready for that, then it gets merged into the trunk.
That's your definition of a 'sandbox' and of an 'experiment'. And even if I buy into that: Nothing prevents me from considering the whole boost trunk to be such an experiment. ;-)
Only that boost doesn't have what other projects call release branches, so you are unable to do bugfix-only releases.
The release branch is almost always ready for release. If a user needs a bug fix or "hot patch" - all he has to do is download it from there. He can either download the whole thing or just the library he's interested in.
That's not the only concern. As lots of people have repeatedly stated on this ML: the point of a bugfix-only release is to fix bugs while fully preserving ABI and API compatibility. Regards Stefan -- ...ich hab' noch einen Koffer in Berlin...
Stefan Seefeld wrote:
Robert Ramey wrote:
So what ? I recently added a new feature to the boost.python library, in a patch I committed to trunk. What if Joe Random tomorrow submits a separate patch, making use of this feature ?
here's the sequence: a) Joe tests his stuff against the latest release and its working: b) you add new feature to the python library and upload it into the trunk and test it. c) After about week of looking at the test results, you're happy with it and now merge it into the release branch. (inlcluding the updated documentation describing the new faciity). d) Joe looks at your new stuff in the release branch and new documentation and decides that its something he want's to use and alters his code accordingly. No problem. They only way there could be a problem is if Joe were to start using the new feature before its merged into the release - which a) is pretty unlikely as he doesn't see it until its merger, and b) is his problem any as he takes a chance on relying on a new interface which is still being tested.
What, then, if the two changesets are (separately !) considered to be merged into some other branch ?
I don't know what other branches. Here is the drill, change sets are merged into the trunk to be tested, then - if testing suggests it a good idea - changes are merged from trunk to release.
There should be no direct dependency between changesets. If there is - its a bug.
Huh ?
yep - its a bug it means that
Library A should depend upon, and only upon, the documented interface of Library B. If merging B into the release branch breaks library A - then either B as changed its interface so it doesn't match the documentation or A wasn't incompliance with the documentation. Either way its a bug.
First, I'm not necessarily talking about dependencies between different libraries, I'm talking about dependencies between patches / changesets, no matter what source they are applied against.
If patches should only depend upon previous patches - how could it be otherwise. Since all patches are merged into the releae branch in order, the the release is always working. I can't see how this can be a problem.
Second, the issue I'm talking about has nothing to do with whether the change is documented or not. The dependency between the changesets needs to be tracked, somehow.
Nope. If all libraries are coded against a documented interface, and the library implements that interface as documented, then there is no need to track anything else.
Third, even if something (library or not) changes in trunk, and something other is added relying on this change. That doesn't yet answer how those two changes percolate into any release branch.
Here's the answer. library A changes in the trunk. Since the changes are "brand new" nothing else can depend upon them. Once they are merged into the release, everyone can depend upon them with out problem. and those dependent libraries will be enhanced, tested and merged into the release when the author feels they are ready. There is no conflict nor ambiguity. ]>> A "sandbox" would be a separate branch where experiments are
conducted. For this one doesn't need all the testing on various platforms - yet. When the "experiment" is ready for that, then it gets merged into the trunk.
That's your definition of a 'sandbox' and of an 'experiment'.
correct, though I don't know how it would differ much from anyone elses.
And even if I buy into that: Nothing prevents me from considering the whole boost trunk to be such an experiment. ;-)
Actually it IS an experiment. Its where code is uploaded in order to be tested in the environments which testers want to see boost support. That's exactly why it is not and can never be "release ready"
Only that boost doesn't have what other projects call release branches, so you are unable to do bugfix-only releases.
The release branch is almost always ready for release. If a user needs a bug fix or "hot patch" - all he has to do is download it from there. He can either download the whole thing or just the library he's interested in.
That's not the only concern. As lots of people have repeatedly stated on this ML: the point of a bugfix-only release is to fix bugs while fully preserving ABI and API compatibility.
I don't know about the current state of things. But if there exists a simple, reliable, automatic and convenient method for creating a release tarball (as there should be), Then just invoke to create a "point release" every time there is library merge into the release ready branch. This is the central requirement for "point release" or "hot fix"' API compatiblity is the library correctly implementing its documented interface. ABI compatibility can only be guarenteed by the user rebuilding the "point release". Neither are related to the procedure for delivering "point release" or "hot fixes" Robert Ramey
Robert Ramey:
There should be no direct dependency between changesets. If there is - its a bug. Library A should depend upon, and only upon, the documented interface of Library B.
Legitimate dependencies do exist. A may depend on a bugfix changeset of B, or a new feature changeset of B.
If merging B into the release branch breaks library A -
_Not_ merging B into release before A is merged may also break the newly merged A.
Peter Dimov wrote:
Robert Ramey:
Legitimate dependencies do exist. A may depend on a bugfix changeset of B, > or a new feature changeset of B.
As I said- that would be a bug. In fact this would be an old bug.
If merging B into the release branch breaks library A -
_Not_ merging B into release before A is merged may also break the newly merged A.
Well, A was already working, then it has already been addressed with some workaround or something like that. The author of A is stuck waiting for the author of B to address it in any case. This doesn't effect things. Unless of course the bugfix breaks the workaround - oh well. Robert Ramey
Robert Ramey:
Peter Dimov wrote:
Robert Ramey:
Legitimate dependencies do exist. A may depend on a bugfix changeset of B, > or a new feature changeset of B.
As I said- that would be a bug. In fact this would be an old bug.
If merging B into the release branch breaks library A -
_Not_ merging B into release before A is merged may also break the newly merged A.
Well, A was already working, then it has already been addressed with some workaround or something like that.
A is working on the release branch against B. A+dA is working on trunk against B+dB. But dA can't be merged into release since it depends on dB. This isn't a big deal in practice since the author of A will simply ask the author of B to merge first.
On Thu, Aug 21, 2008 at 4:54 PM, Peter Dimov <pdimov@pdimov.com> wrote:
Robert Ramey:
Peter Dimov wrote:
Robert Ramey:
Legitimate dependencies do exist. A may depend on a bugfix changeset of B, > or a new feature changeset of B.
As I said- that would be a bug. In fact this would be an old bug.
If merging B into the release branch breaks library A -
_Not_ merging B into release before A is merged may also break the newly merged A.
Well, A was already working, then it has already been addressed with some workaround or something like that.
A is working on the release branch against B. A+dA is working on trunk against B+dB. But dA can't be merged into release since it depends on dB.
This isn't a big deal in practice since the author of A will simply ask the author of B to merge first.
Isn't it also possible that in the interim, B+dB now also depends on A+dA? i.e. neither can merge without breaking the other - they must both be merged at once, or merged in steps to prevent breakage. --Michael Fawcett
Michael Fawcett wrote:
This isn't a big deal in practice since the author of A will simply ask the author of B to merge first.
Isn't it also possible that in the interim, B+dB now also depends on A+dA? i.e. neither can merge without breaking the other - they must both be merged at once, or merged in steps to prevent breakage.
exactly correct. They way to prevent breakage or detect it in a timely matter is a) to test each library against the "release ready" branch AND b) to merge tested libraries into the "release ready" branch one at a time. AND c) test the "release ready" after EACH merge. If there is a test failure there is a bug in one of the libraries. Release Ready branch is broken e) Developers arm wrestle to determine who fixes what. and get it done ASAP. Changes are retested on the trunk and merged again - or maybe the latest merge is backed out. Release Ready branch is now "release ready" again. Robert Ramey
Peter Dimov wrote:
A is working on the release branch against B. A+dA is working on trunk against B+dB. But dA can't be merged into release since it depends on dB.
This isn't a big deal in practice since the author of A will simply ask the author of B to merge first.
Ah Ha - now you've come upon the magic missing piece !!! If tests in the trunk are done against the RELEASE rather than the TRUNK then this situation won'e come up. The trunk test procedure should be. a) Each tester maintains a release ready tree. b) library A gets modified on the trunk c) library B gets modified on the trunk d) each tester does the following: for each modified library switch the directories which contain that library to the trunk run tests switch directories back to release. This would mean that no library is tested against code which is not yet in the release so changes won't be coupled. Robert Ramey
Beman Dawes wrote:
Gennaro Prota wrote:
Daryle Walker wrote:
On Aug 19, 2008, at 8:34 AM, Rene Rivera wrote:
Gennaro Prota wrote: [...]
where does the release branch originate from?
It's always from the previous release.
Is this a good thing?
Not to me. I imagine that, in a time in which I wasn't following the list, there have been long discussions which led to the current state of affairs. So, it may be clear to everyone except me. What I know for sure is that this requires *a lot* of work every time you make a modification; and either a lot of memory on your part, or a file where you note the inter-release changes down, detailedly (I certainly don't trust merging a whole directory (or multiple ones) blindly: I want to see exactly what gets merged; and, to do this, I have to keep a list of what changes I made). With such an approach, I'd expect more problems due to naive merges than problems due to an unstable trunk version being used as a branch point.
Whoa!
Gulp! Isn't that to stop a horse? :-) (Someone warned me about having long hair... <http://gennaro-prota.50webs.com/>).
None of that has to be done manually. Subversion provides plenty of tools to manage differences between trunk and branches/release.
I'll see how it goes. Manually or not, it's a lot of bookkeeping, and requires time. Since I'm only maintaining dynamic_bitset, I'd expect a few number of interventions, thus I'm probably the wrong guy to complain. But it seems to me that being a Boost developer is going to be a full-time job, really. (With the previous repository policy, I could make modifications to a library when I had some spare time, look at the regression reports and forget it. Now, instead, I have also to wait for the release branch to be open and do all the merges; which could be e.g. two months later, in a moment I'm simply unavailable). -- Genny
Gennaro Prota wrote:
I'll see how it goes. Manually or not, it's a lot of bookkeeping, and requires time. Since I'm only maintaining dynamic_bitset, I'd expect a few number of interventions, thus I'm probably the wrong guy to complain. But it seems to me that being a Boost developer is going to be a full-time job, really.
In my view, the current system is a huge improvement over the previous one. It wastes a lot less time.
(With the previous repository policy, I could make modifications to a library when I had some spare time, look at the regression reports and forget it.
Now, instead, I have also to wait for the release branch to be open
The release branch should be always open. Once you're happy with all the test results you can merge from the trunk into the "next release", or "rease ready" or whatever its called branch. This gives the effect of developing on a branch (the trunk) that is actually tested by all the testers. Doing on a branch is a lot of excess work and one's stuff doesn't get tested. Its necesary for big changes and new libraries, but its overkill for smaller changes and maintainence. This latest release has been much less painful than previous ones with just a few snafus. And best of all, these snafus are related to small number of specific libraries and tools rather than all over the place. Now attention seems to be getting focused on these issues whereas before they got lost in all the noise. I'll take this opportunity to beat my drum on my proposed improvement to the current proces: I would like to see the testers start with the Release Branch. for each library which has been changed, the related directories are switched to the Trunk and the tests are run. After the test the libraries directories would be switched back to the release branch. This would give the devoloper a clear picture of the result of his changes independent of any other changes made by other developers. Release Testers would retest whenever one or more libraries are merged into the release. Otherwise the procedure would be the same. Robert Ramey
Robert Ramey wrote:
In my view, the current system is a huge improvement over the previous one. It wastes a lot less time.
OK. [...]
This latest release has been much less painful than previous ones with just a few snafus.
From what I remember (I've been more than one year away) it was just a) the incredible amount of coupling between the different parts of Boost b) code complexity c) absence of Beman. As to point c), I'll better not talk about the release manager who took his place :-) -- Genny
Gennaro Prota wrote:
Robert Ramey wrote:
In my view, the current system is a huge improvement over the previous one. It wastes a lot less time.
OK.
[...]
This latest release has been much less painful than previous ones with just a few snafus.
From what I remember (I've been more than one year away) it was just a) the incredible amount of coupling between the different parts of Boost b) code complexity c) absence of Beman.
Absolultly wrong. a) there is no more or less coupling between libraries than there ever was. b) boost code is getting more complex - not less c) The previous review manager engaged in a heroic effort for almost a year. There has never been any reason to question either his competence to do the job nor his dedication to it. The job as it was defined was just not possible to do. The problem is the following: a) One cannot get his stuff tested until its checked into the trunk. b) Once checked in, the test matrix has to be watched for about a week to check all the platforms. c) During this time the trunk cannot be considered ready for release. d) Within a week - someone else check something in e) All this implies that the trunk is not an can never be ready for release. In the past, this was addressed by attempting to coordinate all the boost developers to check in up to a certain date X and then run the test and have everything pass at once. This can work fine with 1, 2, or even 10 or 15 developers. But obviously it cannot and does not scale. This lack of scaling manifested itself with each release taking more time than the previous one until 2007 when it took a year. The current system decouples unit testing from release. After a library is tested it goes into the release branch as soon as the author and release manager agree that its up to quality. So we have branch (the trunk) where libraries are tested and a branch (release) which contain libraries thougth to be ready to release. Each developer can work at his own pace and it is not required for everyone to be in sync to some special date (which is never met). Perhaps it might be more fitting to name the branches LibraryTesting Branch and ReleaseReady Branch. The only problem that remains are interface breaking changes. The current system highlights these and permits them to be addressed more effectively. Previously they were lumped in with library coding bugs which failed promote the most effective solution. I have hope that this aspect will improve now that its a lot more obvious than it used to be. Robert Ramey
Robert Ramey wrote:
Gennaro Prota wrote:
Robert Ramey wrote:
In my view, the current system is a huge improvement over the previous one. It wastes a lot less time. OK.
[...]
This latest release has been much less painful than previous ones with just a few snafus. From what I remember (I've been more than one year away) it was just a) the incredible amount of coupling between the different parts of Boost b) code complexity c) absence of Beman.
Absolultly wrong.
a) there is no more or less coupling between libraries than there ever was.
Probably more :-)
b) boost code is getting more complex - not less
Yes.
c) The previous review manager engaged in a heroic effort for almost a year. There has never been any reason to question either his competence to do the job nor his dedication to it.
I don't know about competence. But certainly "dedication"... :-) (just to be sure we're talking about the same thing: I'm referring to 1.34.0; he was so missing, all the time, that in a few occasions I have even been ironic about it <http://lists.boost.org/Archives/boost/2006/08/109211.php> ). Yes, getting a release out takes a heroic effort, which Beman (and Rene, I think --sorry if I forget anyone else) has been willing to put in. Others haven't. That's why I said Beman absence was crucial: there is/was no one else with the time and patience to do what he does. And then Beman tried to define a different schema for managing things; isn't that part of his dedication? -- Genny
Daryle Walker wrote:
On Aug 19, 2008, at 8:34 AM, Rene Rivera wrote:
Gennaro Prota wrote:
******************************************************************** branches/release is open for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. ******************************************************************** Hi Beman, Rene, Daniel, I know I should already know this, but I was completely lost in the Wiki pages. Perhaps just the stifling heat we have here. Well, I made several changes related to dynamic_bitset, in trunk, and I thought
Beman Dawes wrote: they would be (now) in the release 1.37 branch. They aren't. So, where does the release branch originate from?
It's always from the previous release.
Is this a good thing? Wouldn't this mean that the releases will diverge from the trunk, increasingly so after each release? I feel that would be _very_ bad. Is there some sort of merging going on between the trunk and release (in either direction, or both)? We don't want fixes and new libraries on the trunk being missed for release.
Right. That's why the release manager runs an "unmerged changes" analysis later in the release cycle and pesters developers who appear to have been lax about merging changes.
Shouldn't the final form of the release workspace be merged back into the trunk (and then the branch [but not tag] deleted), and the next version's workspace branched from the merged trunk?
No. That's the "Wild West" system we used to use. It was a nightmare to manage. The new system is much better since branches/release stays much more stable, allowing us to get releases out quarterly. --Beman
Shouldn't the final form of the release workspace be merged back into the trunk (and then the branch [but not tag] deleted), and the next version's workspace branched from the merged trunk?
No. That's the "Wild West" system we used to use. It was a nightmare to manage. The new system is much better since branches/release stays much more stable, allowing us to get releases out quarterly.
The more I read about how you manage the repository, the more I wonder why you don't do like most projects I have been working with. Maybe that is what you are doing, but I can't get my head around it. ;) What I'm used to is a trunk where general new development goes on ("unstable" if you will, new features/libraries are added here). Then at some point it is decided that a release with the current features in trunk should be made. Let's call this release 1.37, so we copy trunk into a release branch "branches/boost_1_37" or something like that. At the same time we create a tag from this copy "tags/boost_1_37_0" and make a release from that copy. Now we have one tag, the frozen code used for release 1.37.0, and we have two "branches" of development: "trunk" and the release branch "branches/boost_1_37". Now all bugfixes and new development go to trunk. *But* all bugfixes that apply to the 1.37 branch as well are also merged to that branch! This way we always have a "stable" branch ("branches/boost_1_37") with no interface breaking changes, but all bugfixes applied. Users can easily get what you've discussed as "hotfixes" by just checking out this branch. Once there are enough bugfixes in "branches/boost_1_37", it may be decided to release an updated version of 1.37. So we just create a new tag, "tags/boost_1_37_1", from "branches/boost_1_37", and make a release from that copy. We can rest assured that all the bugfixes from that release are still in trunk, because that's where they originate from. Development goes on for some time in trunk, and relevant bugfixes are merged to the release branch. Until at some point it is decided to release 1.38. Same procdedure as last time: Make a new branch "branches/boost_1_38" as a copy of trunk, and create a tag "tags/boost_1_38_0" from that new branch. Now bugfixes in made in trunk go into the new release branch "branches/boost_1_38". At your option also to older release branches to keep the old version up to date for users that don't want to/can't upgrade. I see many benefits from this approach as many things come for free, and it requires little work from all involved. The only important thing developers must remember, is that all new features/interface breaking changes go to trunk, and bugs are fixed in trunk, then merged into the release branch(es). AFAIK new versions of Subversion even helps manage this merging nightmare by automatically keeping track of exactly which revisions from e.g. trunk are merged into each of the other branches. You might want to look into that feature. If an older version of Subversion is used (pre 1.5 I think), then a tool such as svnmerge might help. Just my 2 cents, and as I'm not a Boost developer it doesn't affect me that much, but of course I would like to see regular and stable releases. ;) Best regards, Christian Larsen
On 20/08/2008, Christian Larsen <contact@dword.dk> wrote:
The more I read about how you manage the repository, the more I wonder why you don't do like most projects I have been working with. Maybe that is what you are doing, but I can't get my head around it. ;)
[snip explanation] The main obstacle is testing. We need the feedback from the regression testing to tell if our code works on the large number of platforms and compilers. It seems to be easier to run the tests on two fixed branches. There's some talk of new testing systems which might be more flexible. There also doesn't seem to be anyone willing to maintain the extra branches or point releases. And some boost developers don't seem very keen on working with multiple branches. If we had a culture of shared code ownership, we might be able to make up for that.
AFAIK new versions of Subversion even helps manage this merging nightmare by automatically keeping track of exactly which revisions from e.g. trunk are merged into each of the other branches. You might want to look into that feature. If an older version of Subversion is used (pre 1.5 I think), then a tool such as svnmerge might help.
We're upgrading to 1.5 this week, but I don't think we're going to upgrade the repository format for a while. I've been using svnmerge, but I'm in the minority. The merge data on the release branch is pretty useless because most most developers aren't using it (some seem to actively dislike it). Daniel
Daniel James wrote:
On 20/08/2008, Christian Larsen <contact@dword.dk> wrote:
The more I read about how you manage the repository, the more I wonder why you don't do like most projects I have been working with. Maybe that is what you are doing, but I can't get my head around it. ;) [snip explanation]
The main obstacle is testing. We need the feedback from the regression testing to tell if our code works on the large number of platforms and compilers.
I have yet to understand how testing on trunk tells if your code will work in branches/release. But perhaps I'm just too new to the new repository policy. [...]
There also doesn't seem to be anyone willing to maintain the extra branches or point releases. And some boost developers don't seem very keen on working with multiple branches. If we had a culture of shared code ownership, we might be able to make up for that.
What do you mean by "culture of shared code ownership"? -- Genny
Gennaro Prota wrote:
Daniel James wrote:
On 20/08/2008, Christian Larsen <contact@dword.dk> wrote:
The more I read about how you manage the repository, the more I wonder why you don't do like most projects I have been working with. Maybe that is what you are doing, but I can't get my head around it. ;) [snip explanation]
The main obstacle is testing. We need the feedback from the regression testing to tell if our code works on the large number of platforms and compilers.
I have yet to understand how testing on trunk tells if your code will work in branches/release.
It doesn't necessarily, but if your changes don't cause any regressions on trunk, and you merge to branches/release *and you test locally before you commit*, then you can be reasonably sure they won't cause any surprises. I'll second Robert's emotion that the new system is better than the old, even if it means a little extra work on my end. It's as simple as doing a diff between the code I own on trunk and release before a release to see if there are fixes I need to merge. That's a small price to pay, IMO, for a stable release branch and regular quarterly releases. -- Eric Niebler BoostPro Computing http://www.boostpro.com
On 21/08/2008, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
There also doesn't seem to be anyone willing to maintain the extra branches or point releases. And some boost developers don't seem very keen on working with multiple branches. If we had a culture of shared code ownership, we might be able to make up for that.
What do you mean by "culture of shared code ownership"?
In general (this is a gross generalisation, there are plenty of exceptions) a library is maintained by one or two people and if there is a problem it's up to them to solve it. In a culture of shared ownership (I'm already embarrassed about using that phrase) people would be feel more responsibility for other's people libraries. Because most tasks are up to the individual library maintainers we can only do what they are willing to do. We have good unit tests, because maintainers are willing to write them. But individual developers don't seem willing to maintain multiple branches - which puts the burden onto the people who are (i.e. Beman). I don't want to put down anyone's contribution. I'm just trying to explain the problems that I see with maintaining multiple branches. Some of the suggestions that have been made (such as more modular testing and better merge tracking in Subversion 1.5) might improve the situation considerably. Daniel
Daniel James wrote:
On 21/08/2008, Gennaro Prota <gennaro.prota@yahoo.com> wrote:
There also doesn't seem to be anyone willing to maintain the extra branches or point releases. And some boost developers don't seem very keen on working with multiple branches. If we had a culture of shared code ownership, we might be able to make up for that.
What do you mean by "culture of shared code ownership"?
In general (this is a gross generalisation, there are plenty of exceptions) a library is maintained by one or two people and if there is a problem it's up to them to solve it. In a culture of shared ownership (I'm already embarrassed about using that phrase) people would be feel more responsibility for other's people libraries.
I have to say that sometimes I walk through the open tickets and say "hey, let's fix this... it's easy and the maintainer is probably just busy"; but usually --and here I'm speaking for myself and my own psychology-- either I give up knowing that nobody would appreciate the work, or I *have* to give up given code complexity (who wants to touch things like BOOST_TT_AUX_BOOL_TRAIT_PARTIAL_SPEC2_2_1_A_QUARTER_TO_NINE_IN_BETWEEN_IMPL_WITH_BARRIER)
Because most tasks are up to the individual library maintainers we can only do what they are willing to do. We have good unit tests, because maintainers are willing to write them. But individual developers don't seem willing to maintain multiple branches - which puts the burden onto the people who are (i.e. Beman). I don't want to put down anyone's contribution. I'm just trying to explain the problems that I see with maintaining multiple branches.
Yes. That's fair, IMHO. I for one I'm not willing to "overwork", simply because that isn't recognized here on Boost. There are other communities were you feel much more "part of the play". I'd not bring the case of dynamic_bitset up again, but when I took the library over it was *terrible*; lot of functions didn't even compile (they were never instantiated) and most of them had bugs; some are still ill-specified, because I didn't get any feedback from the list as to how the definition might have been changed. See what the library is now: it doesn't reflect my style and my ideas about software development but it's one of the most stable and bug-free boost libraries. I think it didn't get any real bug report since its rewrite in 2004 (IIRC). Note, too, that here on the list there are people who happily acknowledge everyone's contributions (even too much; I've got a couple of credits from Beman where I hardly commented on a few trifles :-)) and people who tend to think they are the only ones who did the real thing (wasn't it me the person suggesting the implementation of BOOST_WORKAROUND, for instance? or implicit_cast? or...) Believe me, I don't mind about the specific cases above; I'm just explaining what the consequence is: your willing to contribute decreases, even though you certainly didn't contribute with the goal of getting credit in the first place (personally I just like the technical challenge) -- Genny
2008/8/21 Gennaro Prota <gennaro.prota@yahoo.com>:
Daniel James wrote:
In general (this is a gross generalisation, there are plenty of exceptions) a library is maintained by one or two people and if there is a problem it's up to them to solve it. In a culture of shared ownership (I'm already embarrassed about using that phrase) people would be feel more responsibility for other's people libraries.
I have to say that sometimes I walk through the open tickets and say "hey, let's fix this... it's easy and the maintainer is probably just busy"; but usually --and here I'm speaking for myself and my own psychology-- either I give up knowing that nobody would appreciate the work, or I *have* to give up given code complexity
Yes, these things have to work both ways. We're in a tricky position because many of our libraries are low level and support a large number of platforms with all kinds of quirks and incompatibilities. The code often ends up complex and it's hard to make small changes without a fairly deep understanding. Many developers do an admirable job at trying to limit the complexity but it's to some extent unavoidable. A lot of boost is just weird voodoo. Daniel
Christian Larsen wrote:
Shouldn't the final form of the release workspace be merged back into the trunk (and then the branch [but not tag] deleted), and the next version's workspace branched from the merged trunk?
No. That's the "Wild West" system we used to use. It was a nightmare to manage. The new system is much better since branches/release stays much more stable, allowing us to get releases out quarterly.
The more I read about how you manage the repository, the more I wonder why you don't do like most projects I have been working with. Maybe that is what you are doing, but I can't get my head around it. ;)
What I'm used to is a trunk where general new development goes on ("unstable" if you will, new features/libraries are added here). Then at some point it is decided that a release with the current features in trunk should be made. Let's call this release 1.37, so we copy trunk into a release branch "branches/boost_1_37" or something like that. At the same time we create a tag from this copy "tags/boost_1_37_0" and make a release from that copy.
Now we have one tag, the frozen code used for release 1.37.0, and we have two "branches" of development: "trunk" and the release branch "branches/boost_1_37".
Now all bugfixes and new development go to trunk. *But* all bugfixes that apply to the 1.37 branch as well are also merged to that branch! This way we always have a "stable" branch ("branches/boost_1_37") with no interface breaking changes, but all bugfixes applied. Users can easily get what you've discussed as "hotfixes" by just checking out this branch.
That's very similar to the process we used for years. The only real difference being that then we only tested on one branch at a time, so developers usually applied patches first to the release branch and then merged them back to trunk. Getting a release out was a nightmare because it took so long to stabilize the release branch; it took close to a year. In May, 2007, at BoostCon, four of the Boost moderators together with several other long-time Boost developers got together and at Jeff Garland's suggestion decided to base each release on the prior release rather than trunk. It took us awhile to get that process started, but now it seems to be functioning well, and is a day and night improvement over the old way of doing things. Thus it is going to be a tough sell to get us to give up a process that seems to be working and revert to a process that was universally viewed as badly flawed. --Beman
Beman Dawes skrev:
That's very similar to the process we used for years. The only real difference being that then we only tested on one branch at a time, so developers usually applied patches first to the release branch and then merged them back to trunk.
Getting a release out was a nightmare because it took so long to stabilize the release branch; it took close to a year.
In May, 2007, at BoostCon, four of the Boost moderators together with several other long-time Boost developers got together and at Jeff Garland's suggestion decided to base each release on the prior release rather than trunk. It took us awhile to get that process started, but now it seems to be functioning well, and is a day and night improvement over the old way of doing things.
Thus it is going to be a tough sell to get us to give up a process that seems to be working and revert to a process that was universally viewed as badly flawed.
Fair enough. I didn't know the history of why things are the way they are, so thank you for taking the time to explain it. This makes sense, and you're the ones who are working with it, so of course you should decide what suits you best. :) I was just wondering why such process which seems to work perfectly well for other projects is a nightmare in the case of Boost. But I guess the sum of all the libraries make things so much more complicated that it is nearly impossible to manage. Kudos to you all for actually getting releases out the door, it's much appreciated. Best regards, Christian
Christian Larsen wrote:
I was just wondering why such process which seems to work perfectly well for other projects is a nightmare in the case of Boost. But I guess the sum of all the libraries make things so much more complicated that it is nearly impossible to manage. Kudos to you all for actually getting releases out the door, it's much appreciated.
A short time ago in IRC I posited that the difference between Boost and the majority of OSS projects is the developer organization. Most OSS projects fall into two categories: a) Relatively small in team size. b) relatively large in team size. For (a) the management of what constitutes a release and hence how much work is in a release is up to one or two people to decide and implement. For (b) things get rather complicated and various projects manage the complexity differently. But like (a) there is usually a small number of people who get things done. So the spectrum of size happens to work because they simplify the complexity. So what's the difference with Boost? Well, it's the developers. For each release all the developers try and coordinate to get all their libraries in working order at the same time... Have you heard the joke about herding cats? Well it's worse. But that was then, in the < 1.34 days... Now the release system solves the problem by introducing that responsible individual in the form of a gateway into what goes into the release. So what's so special about this? Nothing really... And you can see the same management solution in, for example, the Linux kernel. But there is one difference between Boost and other large OSS projects... Those other large projects then to have a *full-time* *paid* person(s) to do this management work. And as the saying goes... The rest are just details ;-) -- -- 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 Aug 20, 2008, at 1:31 PM, Beman Dawes wrote:
Daryle Walker wrote:
Gennaro Prota wrote:
****************************************************************** ** branches/release is open for merging all stable changes, including bug fixes, and major upgrades to existing libraries. Breaking changes should be coordinated with libraries affected. New libraries may be added with permission of a release manager. ****************************************************************** ** Hi Beman, Rene, Daniel, I know I should already know this, but I was completely lost in
Beman Dawes wrote: the Wiki pages. Perhaps just the stifling heat we have here. Well, I made several changes related to dynamic_bitset, in trunk, and I thought they would be (now) in the release 1.37 branch. They aren't. So, where does the release branch originate from?
It's always from the previous release. Is this a good thing? Wouldn't this mean that the releases will
On Aug 19, 2008, at 8:34 AM, Rene Rivera wrote: diverge from the trunk, increasingly so after each release? I feel that would be _very_ bad. Is there some sort of merging going on between the trunk and release (in either direction, or both)? We don't want fixes and new libraries on the trunk being missed for release.
Right. That's why the release manager runs an "unmerged changes" analysis later in the release cycle and pesters developers who appear to have been lax about merging changes.
If the trunk is kept always release-ready, then the release manager can just dump every file in without asking. It should work with only minor tweaks needed. Also, should we have so many developers potentially messing around with the merging mechanics? Maybe it'd be better to have a small group of people to the integration. This is important when we switch the Subversion server and repository format to 1.5, since an update to svn-1.5's built-in merge control requires everyone to change their client access at the same time.
Shouldn't the final form of the release workspace be merged back into the trunk (and then the branch [but not tag] deleted), and the next version's workspace branched from the merged trunk?
No. That's the "Wild West" system we used to use. It was a nightmare to manage. The new system is much better since branches/ release stays much more stable, allowing us to get releases out quarterly.
1. The "always release-ready" trunk (ARR-trunk) philosophy counters this. 2. Someone in a sub-thread branched from this one noted that the management nightmare has moved from one person to all. Instead of each developer updating his/her part of the trunk at their leisure or as needed, now _every_ developer has to do that AND be vigilant about the release branch, which is effectively a parallel trunk that constantly needs attention. This is bad since we're volunteers that come and go and your suggestion requires everyone to be like the release manager. The ARR-trunk method makes this unnecessary. With a ARR-trunk, we just branch off the trunk, do the minimal testing and fixes that were missed, and ship it. Since the fixes were supposed to be there, we can safely merge them back into the trunk, then kill the branch (after tagging it, of course). A problem from the Wild West days was letting the release branch fester for months (or year) while authors tried to get it release ready because the libraries in the trunk it branched from weren't kept (near) release ready. ARR-trunk developers can't do that because the release branch is too short-lived to be a crutch. Always basing the next release branch from the previous version is like festering by piecemeal. Another problem is that the build, documentation, and testing systems still fall apart when someone looks at them funny. Fixing (or replacing) those, especially so the processes can be as automated as possible, and therefore making the test runners' job as turn-key as possible, will provide the quicker turnarounds needed for the ARR- trunk to work. -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
participants (13)
-
Beman Dawes -
Christian Larsen -
Daniel James -
Daryle Walker -
Eric Niebler -
Gennaro Prota -
John Maddock -
Michael Fawcett -
Peter Dimov -
Rene Rivera -
Robert Ramey -
Stefan Seefeld -
Vladimir Prus