From: "AlisdairM" <alisdair.meredith@uk.renaultf1.com>
Personally I find adding libraries in a minor release to be confusing - I expect a minor version essentially to be patching bugs, rather than adding features.
That's not how most software handles version numbers. Applications regularly add features in minor version upgrades. Dramatic additions of functionality or reworking of existing functionality normally indicate a major version number bump. Patches usually only address bugs, security issues, etc.
I would be in favour of shorter release cycles though, as new libraries come through the review queue. Regular releases like this would probably keep the mainline more stable avoid some of the problems seen trying to get the last 2 releases out the door.
That's come up before. The question is how to effect it. Library developers need some time to insert new functionality and changes to existing functionality between releases. When that happens with multitudinous libraries, the compounding of problems leads to long release cycles. The only thing I can think of to address this is for each library to have its own branch for development. Then, when it is deemed ready, that branch is promoted to an integration branch. If it fails there, the promotion is rolled back until the library is changed, gets required changes in another library, etc. Eventually, all libraries compile and test fine in the integration branch and the whole set can be promoted to a release branch. IOW, promotion for integration should be happening throughout the year, but only when a given library is ready to do so. A release is nothing more than taking a timely snapshot of the integration branch. That also means that those that don't want bleeding edge changes, but want more than was in the last release, can get the latest integrated set of libraries from the integration branch. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;