Re: [boost] [modularization] Are modular releases a goal or a non-goal?

Subject: Re: [boost] [modularization] Are modular releases a goal or a non-goal?
From: Thijs van den Berg (thijs_at_[hidden])
Date: 2014-09-18 07:10:03

On Thu, Sep 18, 2014 at 11:14 AM, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> On 18 Sep 2014 at 11:01, Stephen Kelly wrote:
>
> > >> But, I guess you're saying 'for me it's a non-goal'.
> > >
> > > No,
> >
> > Let me rephrase. The download link on boost.org takes me to a page
> where I
> > can download all-of-boost.zip. My question was whether it should be a
> goal
> > for it to offer boost-static_assert.zip.
> >
> > Your response was along the lines of 'it doesn't matter to me what the
> > download link on boost.org does. Here is my solution...', or with a
> > different paraphrase 'what you describe is not a goal for me. My goal
> > is...'.
> >
> > Or you're saying you want the download link on boost.org to point to
> your
> > tool?
>
> Oh now I see what you're saying. You're saying that the git submodule
> boost.thread should be separately downloadable as boost-thread.zip
> right?
>

>From a user perspective, I would really like something like this:
http://jqueryui.com/download/

This Jquery UI "download builder" compiles a zip for your selected modules
and automatically includes their dependencies in it. If at a later stage
you decide need additional modules then the easiest thing is to get a new
full download and not merge an incremental download. Perhaps another user
experience enhancement would be to have precompiles binaries. When I get
boost I don't worry about the size of the donwload, but more about the
compilation process that needs to follow.

But I think the modularization is not just for user experience. Decoupling
modules should improve maintainability -more atention is paid to interfaces
between them-.

Another aspect is about identity: A monolithic products gets the quality
experience of its weakest chain. If e.g. some submodule have minimalistic
documentation then use users get the feeling that the documentation of
boost as a whole is not very extensive. The same goed for relevance. Some
modules are very relevant and others are not very usefull for some users.
Having a lot of modules packed as a single entity gives a feeling that
there is a big learning curve you'l have to take. Knowing that there are
standalone modules takes away that feeling somewhat.