Robert Ramey <ramey <at> rrsd.com> writes: [...]
The essence of Beman's proposal is:
a) maintain a releasable (stable) version. b) do developement on branches - one branch per development project.
OK, but how? I'm not a subversion expert, but as far as I can tell the following is a reasonable description of what we're facing. If you branch the whole of Boost, developers will have to perform merges each time they want to update their sandbox. These may be inexpensive in terms of repository disk space, but are a much greater PITA than sandbox updates. Otherwise you have to keep into account the fact that Subversion branches influence your directory structure. Branching only the library specific parts with the current structure leads to one of the following alternatives: A - Branch from top level with empty intermediate levels: boost +branches +SERIALIZATION_BRANCH +boost | +serialization +libs +serialization B - Branch as low down as possible: boost +boost | +serialization | +branches | +SERIALIZATION_BRANCH +libs +serialization +branches +SERIALIZATION_BRANCH None of these allow checking out with a single command, unless you resort to heavy use of svn:externals. In this situation the alternative structure that several people propose seems more in line with most of the proposed process changes.
c) Test against the releasable version. d) Once a development project has been successfully tested against the the releasable version i) merge the development project into the releaseable version. ii) retest the whole releaseable version iii) automatically regenerate a deliverable package
Again, how? The notion of a single library test queue requires a form of tool support we currently don't have and even if we had it, I'm not convinced it would be easy to make this scheme work given the current type of discretionary, voluntary testing we have. On the other hand unless additional resources are found there's little else that can be done, apart from a little rationalization and, certainly, fixing the current tools.
This is totally orthogonal to proposals to making independent library versions, changing the source control system, etc.
I believe I've shown that this is not entirely true, at least as far as version control is concerned. I agree that single library versioning, however desirable, is a different matter.
We should try to change one thing at a time. I would suggest do the following in sequence and embarking on one thing only after the previous one has been digested.
a) move to SVN - which seems already underway. b) implement to Beman's test/release proposal c) consider changes required to support independent library versioning.
I still think that what I suggest here: http://svn.boost.org/trac/boost/wiki/AlternateProcessProposal is close to the minimum change we must apply if we want things to take a different turn in 1.35 . Cheers, Nicola Musatti