Re: [boost] [git] Update submodules in boost.git

On Sat, Dec 7, 2013 at 3:45 PM, Dave Abrahams wrote:

Andrey Semashev writes:

...

On Thu, Dec 5, 2013 at 11:43 AM, Andrey Semashev wrote:

...

On Thu, Dec 5, 2013 at 11:07 AM, Daniel Pfeifer wrote:

...

2013/12/5 Andrey Semashev :

...

On Thu, Dec 5, 2013 at 9:37 AM, Daniel Pfeifer < daniel@pfeifer-mail.de> wrote:

...

Tests are run on Boost/develop. To make a new release of Boost, you merge the changes of Boost/develop to Boost/master.

Does that mean that X/develop is not tested?

Yes (and no). It is not integrated into Boost and it is not tested as part of Boost. The same way as the development of zlib is not tested by Debian. Just the releases are integrated and tested.

...

Why is it needed then?

According to gitflow, this is where the development of X happens. It is also tested of course. On its own, however.

So this basically means that each library has to have its own testing farm, and Boost serves mostly the bundling purpose. A possible solution, I guess, but not sure such approach would be beneficial for the quality of Boost. I doubt that individual developers will be able to do the same amount of testing for their library releases as they had with svn.

Actually, thinking about it some more, this doesn't look as a good approach at all. First, the develop branch for the submodules becomes unneeded by the superproject. Individual developers may use it at their discretion but it doesn't matter in the big picture.

And why is that a bad thing? The only purpose of the superproject is as a way of tracking releasable states of the whole library collection.

And releasable states includes "releases" to the automated (jenkins?) builds, unit-test executions, and any other formal testing activities. That should occur mostly off the develop branches of the superproject and the submodule repositories. Once everything is building, passing unit-tests, and otherwise ready for release, then the develop branches are merged into the master branches and tagged. This does not mean that this all happens at the same time. A particular library/tool's submodule repository's development work for a particular release could be merged into their repository's master branch early before the actual release of boost. Hmmm... I just thought of a flaw in the above scheme. Unfortunately, if some people don't like having two branches, they're really not going to like the following which requires even more branches (one for each release!). According to the gitflow diagramhttp://github.com/downloads/nvie/gitflow/Git-branching-model.pdf , there's a bubble pointing to a branch off of develop with the text "Start of release branch for 1.0" and a bubble pointing to develop with the text "From this point on, next release means the release *after* 1.0". Now assume you have the scenario I mentioned above (an early release of a library for the next boost release). You need an individual release branches so that work for the 1.0+ releases can continue on the develop branch. If you don't separate things into separate release branches you have to freeze development on the develop branch. Also, you would need automated builds/tests on develop and all the active release branches. That seems like a lot of complexity. Is there a better, simpler way? Am I worrying about something that doesn't happen much, if at all? Michael

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