Re: [boost] Boost 1.58 schedule available?

Subject: Re: [boost] Boost 1.58 schedule available?
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-01-21 15:28:53

Barend Gehrels wrote
> Is it so weird to ask for a schedule?
> 
> It seems I'm the only one asking this for each release again and again, 
> we really need it.

I'm guessing that your the only one because your the only one that needs
this.

So the interesting question is: why doesn't anyone else seem to need this?

I don't need it because the boost serialization library master branch is
always
in form ready to release (as far as I know).  That is,  it has less bugs
and/or
more features than the previous version (again as far as I know).

Of course I can't say the same for the develop branch - that's why it's 
the "develop" branch.  The boost git branching model has mostly solved
long standing problems that we've traditionally had in this area.  But it
pays to tweak one's development practices to take advantage of it.

> Besides the merging, for which I still think can use a schedule, there 
> are also people using our library, asking when the new version is 
> available, and what's in it.

I believe that your best answer to this question is: "we expect feature
X merged into the release (master branch) on date X.  So any boost
release subsequent to date X will contain this feature"

If this is not soon enough for your purposes you have a couple of options
a) download/cloan the version in the release branch yourself.
b) ask the boost deployment team to schedule an official release
by date Y.

So this get's the monkey of your back.

If you've got 5 team members working on your library (congratulations!!!)
then
I would suggest that you consider tweaking your development practices in the
following way.  ( I know this may sound pedantic and/or patronizing, but
please
indulge me for the benefit of others) Each team member does the following:

a) start with modular boost download from git repo.  Set to master branch.
b) On your library - switch to development branch and make sure it
builds/runs all tests with bjam
c) Create a local branch - if your name is george - you can call it george.
d) make your changes in the source code and re-run the tests
e) if your not satisfied with the new changes go to c) above
f) switch to the develop branch
g) merge in changes from branch george.
h) If your paranoid (as I am), you can re-run the boost build tests on the
library.
i) Notify the team leader that you're going to push changes to the develop
branch.
The team leader might ask you to hold back while some other issue on the
develop 
branch get's addressed.  But he shouldn't have to do this very often, if
ever.
j) push your current develop branch to the git repo. 
k) keep an eye on the develop branch tests.

The team leader can merge the develop to master (release) when he feels
that the library is in a state such that he feels comfortable unleashing it 
upon the world.

Robert Ramey

--
View this message in context: http://boost.2283326.n4.nabble.com/Boost-1-58-schedule-available-tp4671426p4671446.html
Sent from the Boost - Dev mailing list archive at Nabble.com.