Boost logo

Boost :

Subject: Re: [boost] Boost 1.58 schedule available?
From: Barend Gehrels (barend_at_[hidden])
Date: 2015-01-21 16:36:13


Hi Robert,

Robert Ramey schreef op 21-1-2015 om 21:28:
> 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

Thanks for your amusing answer. It is appreciated.

However, I'm still feeling a bit worried that as soon as I ask for a
schedule, which is really about time in a 3-months release cycle,
several people start to give me advices to change our way of working...

About the people asking for release dates, these are from large
organizations. They want official releases, not just a trunk or a clone
of a master. So that discards a). And b) is a very good idea, of which I
did not think before, but... imagine... I'm feeling bothered already to
ask for a schedule, will I then ask for an official Boost release by date Y?

About your proposed way of working - right, that is partly how we work.
But mostly we work in separate github spaces which are merged using pull
requests, the advantage is that a pull request can be reviewed quite
conveniently, as a package, before merging it. I can recommend that.

Regards, Barend


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk