Peter Dimov wrote:
Victor A. Wagner Jr. wrote:
I'm suggesting that the work continue on the mainline towards release and that anyone working on something OTHER than the release, work on a branch. That way as long as we're playing with CVS the testers don't have to do ANYTHING to their already functioning scripts. The only people who will need to worry about weird labels will be those working on stuff unrelated to the release.
FWIW, I agree with Victor. I'd go further and state that the CVS should _always_ be kept in a release-ready form. Any deviations from this ideal should be fixed as quickly as possible. I, personally, always use the CVS version of Boost, I never wait for an "official" release. This model is not well supported. Most energy is invested in releases, which makes them very hard to manage (because the effort is not amortized over time.)
Scheduled releases are still a good thing because they provide a deadline, though.
FWIW - I also agree with the idea that we should strive to have the mainline always "release ready" and that experimentation be undertaken on either local versions or a separate branch. There are a couple of fundamental problems with the current situation: a) testing is not scalable - it now take so much resources that not many can do it. As it gets larger, the problem gets worse. b) testing is a little "too expermental". There are issues with incremental build and testing that, if resolved, could make the process less resource intensive. This would be helpful. c) Library developers make their ehancements and run on the compilers that they have. Then they have to upload to the main line to "see what happens" - now the can address issues related to other compilers - But - now: i) mainline isn't "ready for release" ii) other developer whose packages depend on the uploaded "experimental" code are stymied if the experimental code has a bug. Now this might cause a ripple effect and make libraries fail that depend on the "experimental" upload which wastes a lot of testing resources. So to really "fix" this a couple of things would have to change: a) mainline would always have to be considered "candidate for release" Tarballs would be tested when and only when code where merged from a development branch into the mainline. I would expect this to occurr relatively infrequently - whenever a library maintainer thinks its really ready. (guestimate - one or two weeks) The question to be answered by this testing is "Is this ready for release" rather than "what is the current state of development". Whenever a release came up clean it would be labeled boost 1.32.?? (beta). b) Users who want to download it would be encouraged to do so and file bug reports and upload test results to a new "pending issues" test matices. This would require that the "Getting Started" section of the documentation explain the test as part of the installation process. In fact, we might even want to make the default install a "test" as a side effect of the test is building of all the libraries anyhow. That is - spread the testing around to make it scalable. c) Separate development test on the "development tree" would be similar as it is now except. i) incremental update, build and test would be used - this presumes some fixes - including the detection that Jamfiles have been changed and perhaps library authors being permitted to request a total rebuild. d) Its time to approach some industry players for more support. A company that toutes "Boost Compatibility" on its packaging and or promotional material has to expect to be hit up for some support. Such support could/should consist of: i) running at least the release testing on their own platforms. ii) perhaps providing a platform/compiler for running developmental tests. iii) providing software to developers/maintainers of libraries accepted into boost. Note for the above to work - the developemental and release testing has to be TOTALLY automatic once its setup. I realize that this might sound ambitious - but I think that boost is on the verge of bigger things. Robert Ramey