On Thursday 13 March 2014 11:44:22 Marshall Clow wrote:

On Mar 12, 2014, at 1:59 PM, Barend Gehrels wrote:

...

Hi,

The last message about the release schedule was (if I see it correctly) at January 15, and the calendar is empty.

Is there more news about the release planning? I'm especially interested in the planning for the 1.56 release. This is what I’m thinking about:

Mar 24 master closed for breaking changes. April 7 master closed, except by permission April 10 build beta 1 RC April 14 release Beta 1, reopen master April 28 master closed, except by permission May 1st build RC May 5th release 1.56.0

Do you mean the master branch of the superproject?

On Mar 14, 2014, at 5:01 AM, Tom Kent wrote:

Also, would it be worth doing a pre-beta dry-run, to make sure the build process still works?

The build process definitely does not still work, since at its’ heart is “svn export”. That script will have to be rewritten (and will have to do something similar to `b2 headers` as well) I’ll probably build some pre-beta things before releasing an RC1, at which point other people can bang on it. — Marshall

On 13 March 2014 18:44, Marshall Clow wrote:

On Mar 12, 2014, at 1:59 PM, Barend Gehrels wrote:

...

Hi,

The last message about the release schedule was (if I see it correctly) at January 15, and the calendar is empty.

Is there more news about the release planning? I'm especially interested in the planning for the 1.56 release.

This is what I'm thinking about:

Mar 24 master closed for breaking changes. April 7 master closed, except by permission April 10 build beta 1 RC April 14 release Beta 1, reopen master April 28 master closed, except by permission May 1st build RC May 5th release 1.56.0

Are we going to do this? Since we haven't got the new branching structure in place, I could stop automatically updating the master branch of the super project on Monday, or perhaps on April 7th.

On Fri, Mar 21, 2014 at 6:58 AM, Klaim - Joël Lamotte wrote:

On Fri, Mar 21, 2014 at 12:43 PM, Daniel James wrote:

...

Are we going to do this? Since we haven't got the new branching structure in place, I could stop automatically updating the master branch of the super project on Monday, or perhaps on April 7th.

If the idea is to follow gitflow, then starting a release branch to prepare the release would be the way to go. It would mean that the update is never stopped, the release fixes/changes would get into the release branch and once the release is published, these changes would get merged back to master. That being said, it's the gitflow way but it don't mean that it works for boost: I don't see clearly how this could work with the super project setup. Maybe asking for libraries which want to release something to do this and then have the super repo release branch use the release branch of each subrepo would work but it seem complicated (but automatable like for the master udpate).

If we created a separate branch for the release, the regression tests would never get run against it, since they are hard-coded to master.

...

This is what I'm thinking about:

Mar 24 master closed for breaking changes. April 7 master closed, except by permission April 10 build beta 1 RC April 14 release Beta 1, reopen master April 28 master closed, except by permission May 1st build RC May 5th release 1.56.0

Are we going to do this? Since we haven't got the new branching structure in place, I could stop automatically updating the master branch of the super project on Monday, or perhaps on April 7th.

For preference, I would like to see a clear announcement of what we're doing a good week or two before the process starts. John.

On 21 March 2014 15:14, Fletcher, John P wrote:

Please could there also be clear instructions for what maintainers need to do. I am a new maintainer and have not been through this process before.

Well, It's not clear if this is happening, but mainly you just need to have your changes in a stable condition in master by the appropriate deadlines. You might need to request that the master project is updated if you want to make changes later in the development cycle, but we haven't worked that bit out yet. At some point add a short description of what's changed to the release notes. You can do that at: https://github.com/boostorg/website/blob/master/feed/history/boost_1_56_0.qb... Just click 'edit' to create a pull request. If you don't know quickbook, don't worry about getting it right, I'll fix it up for you. Or you can just email me the details if you prefer. I usually ask people to do this a little bit before the beta release, but you can do it at any time. Also, can you add yourself to the maintainer list? It's at: https://github.com/boostorg/boost/blob/develop/libs/maintainers.txt As before, you can click on 'edit' to create a pull request through the web interface. You'll need to be logged into github. thanks, Daniel

...

...

This is what I'm thinking about:

Mar 24 master closed for breaking changes. April 7 master closed, except by permission April 10 build beta 1 RC April 14 release Beta 1, reopen master April 28 master closed, except by permission May 1st build RC May 5th release 1.56.0

Are we going to do this? Since we haven't got the new branching structure in place, I could stop automatically updating the master branch of the super project on Monday, or perhaps on April 7th.

For preference, I would like to see a clear announcement of what we're doing a good week or two before the process starts.

So.... do we have a release schedule yet? There is still nothing listed on the calendar and IMO something needs to be formally announced in advance rather than just "hey, lets do it now!" ;-) Just my 2c... John. PS would it pay to do a dummy release process *before* starting on the actual release to make sure all the scripts etc still work? Or maybe someone has done this already?

Hi, John Maddock wrote On 23-3-2014 17:39:

...

...

...

This is what I'm thinking about:

Mar 24 master closed for breaking changes. April 7 master closed, except by permission April 10 build beta 1 RC April 14 release Beta 1, reopen master April 28 master closed, except by permission May 1st build RC May 5th release 1.56.0

Are we going to do this? Since we haven't got the new branching structure in place, I could stop automatically updating the master branch of the super project on Monday, or perhaps on April 7th.

For preference, I would like to see a clear announcement of what we're doing a good week or two before the process starts.

So.... do we have a release schedule yet? There is still nothing listed on the calendar and IMO something needs to be formally announced in advance rather than just "hey, lets do it now!" ;-)

So what is the state now? As a background, we're working quite hard on Boost.Geometry, as a team, finishing code, reviewing each others code, merging git-branches, fixing, etc. To decide which features will make it to release, a confirmed schedule would be very welcome. It does not need to be ASAP (a little more time is always welcome), but it is very convenient to know when things should be finished, and to know that (as John suggests) two weeks in advance. Thanks, Barend