|
Boost : |
From: Andrey Tcherepanov (moyt63c02_at_[hidden])
Date: 2008-03-27 23:54:05
On Thu, 27 Mar 2008 14:46:26 -0600, Beman Dawes <bdawes_at_[hidden]> 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. 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.
> 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?
> * 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
> * Release candidate generation and review will begin three weeks before
> the release target date.
>
> --Beman
Thank you very much,
Andrey
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk