Re: [boost] Getting Started with Modular Boost Library Maintenance

Subject: Re: [boost] Getting Started with Modular Boost Library Maintenance
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-12-10 21:05:32

On Dec 10, 2013, at 1:29 PM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:

> Le 10/12/13 17:41, Beman Dawes a écrit :
>> I've been pecking away at "Getting Started with Modular Boost Library Maintenance".
>> 
>> See https://svn.boost.org/trac/boost/wiki/StartModMaint

Thanks for your work on that, Beman.

>> One of the questions that came up was how to number releases for individual libraries.
>> 
>> Say Boost.System wants to do a release before the next full Boost release ships. What do I call it? How do I document it? How do I tag it?
>> 
>> Strawman proposal
>> ------------------------
>> 
>> * Call it "Boost.System 1.55.1 Point Release".

-1

>> * Document it via the "readme" file that GitHub pesters you to add.
>> Contents would give the title of the release and the release notes.
>> 
>> * Create a gh-pages branch with the same release notice.
>> 
>> * Tag it 1.55.1
> 
> IMHO the Boost.System release shouldn't be correlated with Boost versions. E.g. Boost.Thread has version 4.2.0 and it appears on the documentation http://www.boost.org/doc/libs/1_55_0/doc/html/thread.html.

+1

> For libraries that have not a version associated yet, they could start by the version they think it represents better the state of the library. Taking the history of the library should help to see on which version each library is (see http://www.boost.org/doc/libs/1_55_0/doc/html/thread/changes.html). I use to change the major version each time I introduce a breaking change, the minor version when I add more features and the patch when I just add fixes.

Good

> With Git, I guess the author should create a release branch, each time he/she consider it is time to do a release. Of course this would mean that there is at least a version each time the library introduces changes on a official Boost release. This allows to take care of hot fixes independently of the other features the author is working on, which I think is something the Boost users are waiting for.

Right

___
Rob

(Sent from my portable computation engine)