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

Subject: Re: [boost] [git] Update submodules in boost.git
From: Cox, Michael (mhcox_at_[hidden])
Date: 2013-12-07 23:02:55

On Sat, Dec 7, 2013 at 3:45 PM, Dave Abrahams <dave_at_[hidden]> wrote:

> Andrey Semashev <andrey.semashev_at_[hidden]> writes:
>
> > On Thu, Dec 5, 2013 at 11:43 AM, Andrey Semashev
> > <andrey.semashev_at_[hidden]> wrote:
> >> On Thu, Dec 5, 2013 at 11:07 AM, Daniel Pfeifer <daniel_at_[hidden]>
> wrote:
> >>> 2013/12/5 Andrey Semashev <andrey.semashev_at_[hidden]>:
> >>>> On Thu, Dec 5, 2013 at 9:37 AM, Daniel Pfeifer <
> daniel_at_[hidden]> 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
diagram<http://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
>