Rene Rivera:

I thought that was clear from previous messages, but I'll mention what my understanding is... "branches/release" is for 1.36.0 *only*. There needs to be another branch for 1.35.1 (perhaps "branches/release_1_35_1") which I would guess the manager for the 1.35.1 release would take care of by branching from "tags/release/Boost_1_35_0".

Which would lose all fixes currently on the branch.

As for the starting point for 1.36, it's always been the rolling "branches/release" i.e. 1.35.x, which is now the 1.36.x branch :-) It also means that patches that go into the 1.35.1 branch would also likely need to go into the 1.36.x branch.

Yep. This is how things were intended to work. The question is whether we need to reevaluate that. The single branches/release presupposes that only one release is active at a time. Given the proposed schedule, this can only be true if we drop the .1 releases. If we don't, it might be wise to revisit the old practice of using a separate branch for every release family - release_1_35, release_1_36, and so on. It might also be interesting to give the "starting point" question another look. I think that the trunk is quite competitive as a starting point for 1.36, because it is currently being integration tested, whereas release+merges is not.

From: "Marshall Clow" <marshall@idio.com> Newsgroups: gmane.comp.lib.boost.devel

So .... I guess the question is: With a release of boost every 3 months, do we need point releases (except in the case of a big mistake)? To put a very fine point on it, is there a reason to do a 1.35.1 release as well as a 1.36?

I echo this sentiment because I see how hard the release team have to work for each release. Very much appreciated. Perhaps an alternate strategy for interim fixes that explicitly creates just a set of patches or updates could be formalised (or have I just missed it)? I'm never sure what branch I need to retrieve to solve this. Perhaps always having one labelled '1_35_latest_bugfix' is sufficient to get people started. Thanks team, looking forward to a smooth 1.36

Hi! Bo Persson schrieb:

We might want to consider how users of the library see this. Is it certain that everyone wants feature changes every quarter, or is bug fixes for an existing release more useful?

I agree. I prefer releases every six months. But bug fixes should be released sooner ;) Frank

Peter Dimov wrote:

Rene Rivera:

...

I thought that was clear from previous messages, but I'll mention what my understanding is... "branches/release" is for 1.36.0 *only*. There needs to be another branch for 1.35.1 (perhaps "branches/release_1_35_1") which I would guess the manager for the 1.35.1 release would take care of by branching from "tags/release/Boost_1_35_0".

Which would lose all fixes currently on the branch.

True, but it should be easy enough to merge specific changes from "branches/release" to a 1.35.1 branch.

I think that the trunk is quite competitive as a starting point for 1.36, because it is currently being integration tested, whereas release+merges is not.

Well the testing of "branches/release" has never stopped. -- -- 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

2008/5/23 Peter Dimov <pdimov@pdimov.com>:

...

Well the testing of "branches/release" has never stopped.

It doesn't matter, because the current state of branches/release is largely irrelevant (except if released as 1.35.1).

I don't think it should be a question of if released as 1.35.1, but I think it should be a given that if bugs are present in a particular release, that can be fixed, keeping as much of the ABI/API the same then these bugs should be fixed. Since large changes are allowed in modules between point releases then it is useful to have bug fix releases that fix issues with the release since upgrading may not be an option, due to time constraints or project budgets, if there has been a API change, so its useful to have working versions of a release.

What is relevant for 1.36 is the state of branches/release after the merges from trunk are done, and this isn't being tested, because it doesn't exist yet.

As to branch management I think that the best method for boost will be to name the branches after the major release number i.e. so the next release development will be occuring on branches/release1_36 and not just branches/release. This makes repository management a lot easier in the long term too (should boost move to a distributed version control system this branching convention will be a lot easier to import). So what I would propose is this: branches/release gets moved to branches/release1_35 and a 1.35.1 release be made from fixes on this - not a huge amount of work since essentially just patching up from trac bug reports, ensuring changes are also merge on trunk and release1_36 (where applicable). branches/release1_36 gets made from trunk asap Then development for 1.36 happens alongside 1.35.1. Ideally the branch for 1.36 would have been made after feature freeze for 1.35 occurred. The reason for this is that it enables trunk to become a stabilising area for features for the next release i.e. it implicitly becomes release1_n+1(any features not ready for integration should be developed on a feature branch branched from trunk to be later merged back to trunk). Before 1.35 was released I did try to start discussion that 1.36 should be branched before the actual release (i.e. when a feature freeze began) and that the release team for 1.35 should then continue to manage the branch for bug fixes and that a second release team should begun integration for 1.36. I think a good model for boost's release procedure would be one similar to that of the linux kernel. Having a merge window for a particular release for new features, then a stabilization period before releasing could suit boost well due to the nature of the project. James

Peter Dimov wrote: [...]

Yep. This is how things were intended to work. The question is whether we need to reevaluate that. The single branches/release presupposes that only one release is active at a time. Given the proposed schedule, this can only be true if we drop the .1 releases. If we don't, it might be wise to revisit the old practice of using a separate branch for every release family - release_1_35, release_1_36, and so on. It might also be interesting to give the "starting point" question another look. I think that the trunk is quite competitive as a starting point for 1.36, because it is currently being integration tested, whereas release+merges is not.

The discussion in this thread resembles the one about which branch 1.35 was to be based on. Although the much shorter delay makes it a smaller problem, a "runaway" trunk is still a problem. Given how cheap branches are in svn I don't think it makes much sense for trunk to be the sort of anarchic playground it appeared to be at times in the past. In my opinion all releases should be based on trunk and branched immediately before the first release candidate is issued. Most development activity should take place in specific branches that are merged to trunk at appropriate times. For instance immediately after a release branch is created would be a perfect moment to merge new libraries in. Whether point releases take place would depend on the availability of fixes and of release management voluntaries, but making them should be as simple as possible. This is more or less how it is done for gcc, and it appears to work for them. Cheers, Nicola -- Nicola.Musatti <at> gmail <dot> com Home: http://nicola.musatti.googlepages.com/home Blog: http://wthwdik.wordpress.com/

Peter Dimov wrote:

Beman Dawes:

...

The 1.36.0 release schedule has been set. For details, see http://svn.boost.org/trac/boost/wiki/ReleaseSchedule

No mention of 1.35.1? I (and others) have been committing fixes to the release branch, expecting it to become .1 some day. Will it? As a release manager of the 1.35.x family you ought to have an opinion. :-)

It is fine with me if someone else manages a 1.35.1 release, although it isn't clear to me who that someone would be. Dave Abrahams is interested, but I doubt he has the time available. I'm personally concentrating on smoothing out the regular quarterly release process so that releases happen as scheduled and with more quality assurance than is currently the case. That leaves me no time to manage point releases.

If yes, we'll need two release branches, one for 1.36.0, one for 1.35.x.

Yes. branches/release will be for 1.36.0. I haven't given any thought to what the other should be named.

Either way: what would the procedure for the 1.36 branch be? What is its starting point,

branches/release

and who's going to do the merging?

Each individual library's maintainer. That's the only approach I know of that scales, and avoids the release managers becoming bottlenecks. Good questions, thanks! --Beman

2008/5/24 Jens Seidel <jensseidel@users.sf.net>:

On Sat, May 24, 2008 at 07:22:06AM -0400, Beman Dawes wrote:

...

Peter Dimov wrote:

...

If yes, we'll need two release branches, one for 1.36.0, one for 1.35.x.

Yes. branches/release will be for 1.36.0. I haven't given any thought to what the other should be named.

How about the usual name: branches/stable?

Again let me reiterate, I'd advise against trying to keep a constant branch name such as branches/release or branches/stable just because moving branches in the repository is a bad idea, just include the version number in the branch name! This kind of system works if you have a good merge tool, but quite frankly subversion is a rubbish tool for doing merges; distributed version control systems provide far better merge tools that enable this kind of integration to be done easily; again I refer people to the example of the linux kernel or git for how this kind of thing is done.

...

...

Either way: what would the procedure for the 1.36 branch be? What is its starting point,

branches/release

Maybe this could be renamed into branches/next_release.

Try to avoid moving branches as I suggested earlier it makes it harder to migrate to other version control systems in the future and also plays havoc with working copies if a new branch with the previous name is then created again as subversion doesn't detect the move. This is part of the reason I consider subversion's branching model of using paths for branches to be broken.

It is fine with me if someone else manages a 1.35.1 release, although it isn't clear to me who that someone would be. Dave Abrahams is interested, but I doubt he has the time available.

I'm personally concentrating on smoothing out the regular quarterly release process so that releases happen as scheduled and with more quality assurance than is currently the case. That leaves me no time to manage point releases.

Do you not consider point releases as part of the release schedule? I think given Boost's complexity that point releases should be a given and in fact that point releases will help increase quality assurance since they are fixing the very problems that slipped through the net for the current release. IMO the only way to get a smoother release process is to instigate hard feature freezes for releases. I can't help but feel from observing the release process that too many last minute features are allowed in; this is kind of a chicken and egg problem; these features are pushed to go into the release because of the long release times, but at the same time its these addition of features that slow the release down at the same time. James

2008/5/24 Jens Seidel <jensseidel@users.sf.net>:

Is this true for Subversion 1.5 as well? This weekend will a release candidate be published, the release is planned one week later. This new merge command is interactive and seems to work well.

I've no idea, I've not been following the 1.5 release schedule, but I think that distributed tools that have the entire history in the working copy are still going to have far better merging capabilities because it simply doesn't need round trips to the server; Subversion is painfully slow once you've seen how quickly git et al. can do merges.

I don't know git (but try to use it) and merging in other distributed version control systems (such as darcs, mercurial).

...

better merge tools that enable this kind of integration to be done easily; again I refer people to the example of the linux kernel or git for how this kind of thing is done.

...

...

Maybe this could be renamed into branches/next_release.

Try to avoid moving branches as I suggested earlier it makes it harder to migrate to other version control systems in the future and also

I can verify this for git-svn or however it is called (git functionaliy over svn). I just assumed the migration tool is buggy and that one just has to file a bug report (not yet done) ...

I guess it can be detected and worked around via the import scripts BUT I think that it is really subversions structure (or lack of) that is the problem and makes it impossible to automatically detect every possible case that could have occurred in the history. (svn:externals are also a big problem in importing too but thankfully boost doesn't make use of them)

...

plays havoc with working copies if a new branch with the previous name is then created again as subversion doesn't detect the move. This is

I think this has changed recently (ehm, I mean in 1.5): * 'svn update' now sometimes copies or moves local files, for efficiency

Does it work in this case?: svn co http://foo/branch/release (some one else moves branch release to be release_last then creates a new branch release) svn up It certainly didn't last I tried it with 1.4. (It's also unclear what the expected behaviour should be: should svn up now retrieve release_last or release?)

...

part of the reason I consider subversion's branching model of using paths for branches to be broken.

James, you should not consider software such as Subversion as static. If you don't like a aspect and others agree with you just report it and wait for the fix (or even better provide a patch).

I don't consider it as static, but this isn't the only gripe I have against subversion. I've worked with subversion extensively and have now moved all my personal code projects to use git as I find it far more usable (the only downside I currently see in distributed systems is the inability to restrict access to parts of the repository; one case where I've used subversion is a commercial repository that is shared between companies. Due to licensing and security issues some of the code is only visible to certain developers, I guess the solution is to use a separate repository for the restricted code but that also has its downsides). Besides I don't think that subversion would move away from using paths for branches since its at the very core of how it has been designed (the model seems attractive at first but in reality it becomes a pain as it allows users to do very silly things to the repository)

2008/5/24 Jens Seidel <jensseidel@users.sf.net>:

Calling "svn up" from the current directory would update all subdirectories. So release/ would be deleted and release_last/ created. After this the new release/ is fetched.

But that's assuming that you have the branches directory checked out, if you don't then the following case applies:

If "svn up" is called from inside release/ nothing would happen, as the content of this directory (with URL .../release_last@HEAD) was not changed.

but would the URL be release_last@HEAD? I don't think subversion would update the working url in this case? I don't think it would in this case without doing a switch or switch --relocate (at least not with versions <= 1.4 I don't know about 1.5). I don't really find renaming obscure, its just that I think that subversion is just rather bad at dealing with it due to the fact you need two pieces of information(url and revision number) to uniquely identify a piece of code whereas git just uses one: a SHA1 hash.

Do you have experiences with git-svn? Maybe by importing Boost's code?

Yes I do. I'm currently using git-svn with Gnome (I'm doing google summer of code with them). I thought I'd imported Boost's trunk at one time, but checking now it appears I've only got the sandbox+branches. I'll have a go at doing the main trunk but obviously it'll take some time. If I'm successful I'll quite happily make the repository available for people to try out using git-svn.

2008/5/24 Frank Birbacher <bloodymir.crap@gmx.net>:

Hi!

James Sharpe schrieb:

...

Besides I don't think that subversion would move away from using paths for branches since its at the very core of how it has been designed (the model seems attractive at first but in reality it becomes a pain as it allows users to do very silly things to the repository)

Attractive Model? Can Do Silly Things? That's the same as with C++, isn't it?

Indeed albeit one that most people are less familiar with the silly things that can be done(and also that they only bite further in time)

The flaw IMO is that the svn up does not follow renaming. But you would only want it if the root of your working copy moved. If only a subdir moved, i.e. current location was deleted, you don't want svn to switch your subdir to the new location.

There are issues with svn. But the model is simple and works quite well. Just because the "svn up" command doesn't cope with renames, well, just always use "svn switch $MY_SVN_URL@HEAD ."

Point taken, but its far from ideal since it requires me to remember the url or look it up when I need to update. Yes it is a simple model that works for the most part, but currently makes things harder than it needs to be when it comes to merging changes; just try a distributed VCS and you'll see how easy merging becomes, and in fact also how much easier branches are too for that matter. Don't get me wrong subversion is a great tool, but I think that the next generation is taking over; its reminiscent of the move of projects from cvs to svn; a lot of projects said cvs works fine for us until they made the move, at which point the benefits of svn became clearer. I believe we're seeing a similar move with distributed version control systems, which in general is an enabling tool for open source; it enables easy forking, branching and contributions, and in fact promotes higher quality patches and history due to history rewriting and being able to commit offline(which for me is one of the biggest advantages of using a DVCS over subversion; I can keep local patches in my own repository until they're tested and proven ready for integration upstream) Take a look at Linus' presentation on git http://www.youtube.com/watch?v=4XpnKHJAok8 for more information on how git differs from CVS/SVN. Anyway I feel this discussion is wandering OT, since we've lost focus on the topic at hand: the release process; the fact is we can use DVCS (be it git, bzr etc...) over the current subversion repository (conversion to these tools can be considered at a later date once a few developers have experience of using them for boost) and that these tools help in easing merging of branches, which is IMO the key part of easing the release process. Obviously one of the biggest consideration when we start to talk about more use of branches is that of testing; how do we distribute our testing resources sufficiently over the branches? This is where I think that branching from trunk as the next stable release as opposed to release is an advantage. Current policy states that regression tests on trunk must be stable before being merged to release, but obviously where library interdependencies come into play this change might not be quite so stable on the release branch, I think that branching from trunk is a better policy and then reverting changesets that cause regressions, at point of release, if they can't be fixed. This is a similar model to what the kernel uses: have a merge window in which some destabilization is allowed. The remainder of the release time is then stablization of the release. The way I would envisage this style of process working for boost is: * stable feature additions/bug fixes occur to trunk at any point in the release cycle * on a given date(on day of release of first of previous release series - there's no point in waiting to branch!) trunk is branched to the next release branch (this date is made know well in advance so developers know that towards this date they should be stablizing regression tests on trunk ready for the branch) Release testing resources begin testing this branch (these release testers should run at least once a day, but preferably on every commit) * this release branch is used for a series 1.x.y - 1.x.z, a release manager is assigned to look after this branch of releases * the first release 1.x.0 is released with a similar process from the six weeks mark that Beman describes at http://svn.boost.org/trac/boost/wiki/ReleaseSchedule although the timescale can now be modified to lengthen the bug fix changes - there should be NO new features(and in most cases no changes to the API - this gives a longer period for documentation to be checked) added though since this should be done on trunk before the release. After a certain date (maybe 4 weeks before release) if a feature is still causing large regressions at the discretion of the release manager this change can be reverted. * Once the release is done the testers for this release branch are reduced to an on commit testing regime (they will also now be testing for the next release branch that has just been created) and this branch is now only committed to for regressions from the release state of the regression tests and bug fixes filed against the last release in trac. No other commits should be allowed on this branch. Then point releases are made fortnightly while there are fixes to be released - this branch is of lower priority with the testers ( but should additional resources become available then more frequent tests can occur) * In this scheme development of potentially disruptive or breaking changes should be initially developed on a branch (using distributed tools this could in fact be a potentially non-publically visible branch - which can then be rebased as a series of commits against trunk). This can then be merged into trunk just after a release branch has been created in order to maximise the time for stabilizing this change against the regression tests. Comments on this as a proposed release structure?

James Sharpe wrote:

Another quick thought on an improvement to the regression test results: it'd be nice to see the history of whether tests were previously passing or failing for a given revision i.e. if a test is currently failing what was the last revision number that it successfully ran at? Likewise being able to see a particular tests history can make bug finding easier; if a test result over time is fail pass fail, knowing what change caused the test to go green can help understand the nature of a bug.

There's a effort going on right now to make over the whole regression testing system. The sort of thing you suggest above is one of the high-priority goals. --Beman

Beman Dawes:

Peter Dimov wrote:

...

Beman Dawes:

...

The 1.36.0 release schedule has been set. For details, see http://svn.boost.org/trac/boost/wiki/ReleaseSchedule

No mention of 1.35.1? I (and others) have been committing fixes to the release branch, expecting it to become .1 some day. Will it? As a release manager of the 1.35.x family you ought to have an opinion. :-)

It is fine with me if someone else manages a 1.35.1 release, although it isn't clear to me who that someone would be. Dave Abrahams is interested, but I doubt he has the time available.

OK. To explain why the question is important, and why the proper time to ask it is now: Developers need to know how to deal with bug reports against x.0. The usual procedure is to issue x.1 with the bugs fixed. For this to happen, the bug fixes need to be committed somewhere. Currently this somewhere is the release branch due to lack of alternatives. If we're leaving the x.1 door open, we need to address this question, and we need to address it before parts of trunk get merged into the current release branch. One easy way is to copy release to release_1_35 so that the 1.35.0 bug fixes have a place to go. The obvious problem is that no tests would be running against that branch. Another alternative is to release 1.35.1 first from the current release branch, then start 1.36. The obvious problem is the possibility of 1.35.2. A third alternative is to declare that we're no longer going to issue point releases. This implies that the proper place to fix bugs against x.0 (before the x+1.0 merges happen) is on trunk.

I tried to merge Boost Exception into the release branch but I got this error: REPORT request failed on '/svn/boost/!svn/vcc/default' Cannot replace a directory from within Could this be because there is no boost/exception directory in the release branch? Any ideas? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Fri, Jun 20, 2008 at 9:16 AM, Rene Rivera <grafikrobot@gmail.com> wrote:

Hm, is there an email delay problem with the list server?

Matthias Troyer wrote:

...

I'm a bit confused about the release process - should we have the changes on the trunk or the release branch? I assumed the trunk but maybe I need to move them to the release branch?

You need to merge to the release branch as has been mentioned in the past <http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromdevelopmenttrunktoreleasebranch>.

-- -- 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

I followed the instructions here: http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromde... (I'm using using Tortoise) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Sat, Jun 21, 2008 at 10:42 AM, Henrik Sundberg <storangen@gmail.com> wrote:

2008/6/21 Emil Dotchevski <emil@revergestudios.com>:

...

I tried to merge Boost Exception into the release branch but I got this error:

REPORT request failed on '/svn/boost/!svn/vcc/default' Cannot replace a directory from within

Could this be because there is no boost/exception directory in the release branch? Any ideas?

Exactly which command did you use (ie full commandline)?

/$ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Matthias Troyer wrote:

I have actually waited for a new release branch to be created for 1.36, since I had always assumed that that branch was for the 1.35.1 release. Well, it seems that unless we still get permission to mere changes 1.36 will go out with the same bugs as 1.35

The release branch is still open for bug fixes. -- Eric Niebler BoostPro Computing http://www.boostpro.com

You see its this lack of flexibility and clarity that naming a branch release brings. I refer you to my earlier suggestion of including the release number in the branch name to remove ambiguity and make it easier to create for example 1.35.1 whilst release 1.36.0 is in progress since it is clear where fixes should go. Can I also suggest that people try out using git-svn for cherry picking their commits. From memory you'd clone the repository as I outlined in an earlier thread, then do: git checkout -b release release gitk --all Then find the commits you want to cherrypick, right click and select cherry-pick. Exit gitk Push back to svn: git svn dcommit On 6/21/08, Matthias Troyer <troyer@phys.ethz.ch> wrote:

On Jun 20, 2008, at 6:16 PM, Rene Rivera wrote:

...

Hm, is there an email delay problem with the list server?

Matthias Troyer wrote:

...

I'm a bit confused about the release process - should we have the changes on the trunk or the release branch? I assumed the trunk but maybe I need to move them to the release branch?

You need to merge to the release branch as has been mentioned in the past <http://svn.boost.org/trac/boost/wiki/ImprovingPractices#Mergingchangesfromde...

...

.

I have actually waited for a new release branch to be created for 1.36, since I had always assumed that that branch was for the 1.35.1 release. Well, it seems that unless we still get permission to mere changes 1.36 will go out with the same bugs as 1.35

Matthias

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- Sent from Google Mail for mobile | mobile.google.com

I am following the traffic on this mailing list yet the first time I noticed anything about releasing 1.36 it was the message informing me that technically I'm late to merge Boost Exception into the release branch. Maybe I have missed an earlier message but I think we should be getting more reminders here. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode On Sun, Jun 22, 2008 at 6:14 PM, David Abrahams <dave@boostpro.com> wrote:

James Sharpe wrote:

...

You see its this lack of flexibility and clarity that naming a branch release brings. I refer you to my earlier suggestion of including the release number in the branch name to remove ambiguity and make it easier to create for example 1.35.1 whilst release 1.36.0 is in progress since it is clear where fixes should go.

I agree with this suggestion. Naming the branch "release" does seem a bit like needless invention where an industry-standard practice would do the job better. Am I missing something?

-- Dave Abrahams BoostPro Computing http://www.boostpro.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost