Andrey Tcherepanov wrote:

Beman,

May I humbly suggest "release more often" item as well? Say, as soon as 1 or 2 new libraries are accepted, merged into release branch and it is stable? Or even "try to release at least last-dot-bug-fix release every 2-4 months"?

Good points. We are aiming for a quarterly release. 1.35.0 took five months, but our infrastructure and procedures are improving, so I hope the next one can be done in three months. We probably need to be a bit more specific about schedules. For example, a twelve week schedule might look something like this: * New libraries, major revisions of old libraries, and big infrastructure changes need to be merged in the first three weeks. * Minor fixes can be merged up until three weeks before the release target date. * Release candidate generation and review will begin three weeks before the release target date. --Beman

Andrey Tcherepanov wrote:

On Thu, 27 Mar 2008 14:46:26 -0600, Beman Dawes <bdawes@acm.org> wrote:

...

We are aiming for a quarterly release. 1.35.0 took five months, but our infrastructure and procedures are improving, so I hope the next one can be done in three months.

I hope too, but it is very hard to enforce 3 (or any other as it matters) months period. I think it is might be worth a try to have something like "another library - another dot release" policy in addition to 3 month bugfix releases cycle.

It is far too expensive in terms of the release management team's time to put out point releases in addition to quarterly releases. And we still have a way to go to get to reliable quarterly releases.

This will help to avoid situation when library got accepted long time ago, but it is not available in release yet just because there is no release. This will also allow new libraries authors to finish the work not too long after review and acceptance - we saw cases when library author has 2-3 months period that he/she can dedicate, but it become an isssue half a year later.

I really think that problem will evaporate if we can get on a regular quarterly release cycle.

...

We probably need to be a bit more specific about schedules. For example, a twelve week schedule might look something like this:

* New libraries, major revisions of old libraries, and big infrastructure changes need to be merged in the first three weeks.

Does it mean that review schedulle has to be adjusted too?

No, it is much better if that schedule runs asynchronously. If the schedules are synchronized, and one stalls, then that forces the other to stall.

...

* Minor fixes can be merged up until three weeks before the release target date.

Then we better have a definition what is minor and what is major fix. I can imagine that major is something tha affects multiple libraries and/or regression tests. But for minor - is it

Yes.

...

* Release candidate generation and review will begin three weeks before the release target date.

Thanks for your comments, --Beman

Richard Newman wrote:

First off, congratulations on your 1.35.0 R3 and near release. It's a lot of work updating infrastructure and in the midst of it often thankless.

Thanks, but don't forget the rest of the release team. Rene and Daniel did a great job, and many other pitched in from time to time. The folks who do the testing are a big part of the process too, and they deserve a lot of credit.

Beman Dawes wrote:

...

Andrey Tcherepanov wrote:

...

Beman,

May I humbly suggest "release more often" item as well? Say, as soon as 1 or 2 new libraries are accepted, merged into release branch and it is stable? Or even "try to release at least last-dot-bug-fix release every 2-4 months"? Good points.

We are aiming for a quarterly release. 1.35.0 took five months, but our infrastructure and procedures are improving, so I hope the next one can be done in three months.

I'm questioning your point that 1.35.0 took 5 months.

My arithmetic was faulty; we worked on 1.35.0 actively for 6 months.

1.34.1 was released on July 24, 2007, more than 8 months ago. Does this mean you didn't "start" a release until 5 months ago?

Right.

Is the delay between finishing a release and starting the next one part of the issue in improving the frequency of releases?

Yes. This time we should do a lot better - there be a week or so delay while I'm distracted by non-Boost activities, but then we should be able to start right away on 1.36.0. And the testing infrastructure is in *much* better shape, so we should come up to speed on 1.36.0 work much more quickly.

Should the next release team be ready to go as part of the release process rather than as an afterglow activity?

Yep. We will start that discussion in a day or two.

...

We probably need to be a bit more specific about schedules. For example, a twelve week schedule might look something like this:

* New libraries, major revisions of old libraries, and big infrastructure changes need to be merged in the first three weeks.

* Minor fixes can be merged up until three weeks before the release target date.

* Release candidate generation and review will begin three weeks before the release target date.

As a "client" of the boost process, we'd probably upgrade once every 6 months, but quarterly gives us a choice of two releases in that period. That choice would depend somewhat on perceived stability. For instance, under the present system, we tend to take the x.y.1 releases over the x.y.0 releases because we perceive the x.y.1 to be of higher reliability. Longer than 6 months and we start pining away for the new libraries and improvements.

I'm good with the current paired release heartbeat of library/major additions (x.y.0) and maintenance/reliability improvements (x.y.1), but together each pair should occur at least semi-annually. Quarterly releases can do this or some other heartbeat. In principle, monthly/weekly/nightly releases are possible (if testing and building are sufficiently automated), but then certain ones become anointed as the "real" releases anyway. Regardless, we'll just pick one of them every 6 months to actually deploy.

That's a very reasonable way manage deployment. We will continue to build nightly snapshots, so those who want to be on the bleeding edge can go that route, too. Thanks for your comments, --Beman

On 27/03/2008, Jonathan Franklin <franklin.jonathan@gmail.com> wrote:

This is a dumb question, but what exactly do we mean by an 'inspection error'?

'inspect' is a tool that lives in 'tools/inspect'. It reports on errors and some violations of boost guidelines. There are links to daily trunk and release reports at: http://beta.boost.org/development/testing.html#Inspection Beman, the trunk report is only showing copyright and license errors, can you change that? Daniel

Jonathan Franklin wrote:

This is a dumb question, but what exactly do we mean by an 'inspection error'?

An error (or maybe they should be called issues) identified on the inspection report. See http://boost.cowic.de/rc/inspect-snapshot.html The only way to learn is to ask questions:-) --Beman