On 01/05/07, Jeff Garland <jeff@crystalclearsoftware.com> wrote:

After the '1.34 experience' I've become even more of an advocate a hard line release approach. That is, we should set the deadline and only accept code that can make it in the release timeframe -- if it's not ready then we take it out and let it slide to the next release.

To minimize risk of delay and release the pent-up backlog of new libraries I believe we should hold all existing 1.34 libs constant and only add in new libraries that are basically ready to go now. I've actually done an 'alpha test' of this approach and it looks like this will work -- that is, most of the unreleased libraries can be build against a 1.34 core without dependencies on changes to existing libraries (there are a few minor exceptions). Behind the scenes I've been encouraging developers of new libs to get their code into CVS so we will be ready to begin the nano-second after 1.34 ships.

Not wanting to detract from the 'move to subversion' discussion (which I-for-one am glad is happening), I've been wondering about the what 'hard line release approach' entails. FWIW, to me this would imply a skeleton policy like so: a) Set a monthly/2 monthly/whatever deadline for a release. b) Straight after each release, a new branch is formed for the release testing c) If a developer thinks a library of theirs is 'ready' then they add it to the testing branch. Regression tests are done on these libraries d) As the deadline approaches and an RC branch is created, libraries that pass tests can be added. Tests are still only done on the testing branch (assume the RC branch code is the same as the testing branch code) e) At the deadline the release is done, following the normal rules: minor increment for updates, major increment for new libraries. Obviously that is a very raw suggestion and ignores the possible complexity of making regression test scripts work with this, about which I know nothing. Concerns it addresses are: 1) Library maintainers don't have to wait a long time to add fixes to their library - something which means the boost repository stays out of date with the developers' own since there's little point keeping two up to date. 2) New libraries could potentially be added at any point. 3) HEAD will be usually be comparable to RC 4) Release quality won't be compromised (in theory). They're just things I've been mulling over for a few days. Thoughts? Darren