On 04/10/12 20:28, Rob Vesse wrote:
Andy
Is it worthwhile for us as a PMC to try to adopt a planned regular release
cycle?
This could either be dates when we aim to produce a new release e.g. 1st
of the month each quarter or it could just be a general aim of a new
release within N months of the previous release e.g. 3 months after the
previous release.
The latter might be a better option for us as it gives us the flexibility
to make a new release sooner if there are important changes/fixes we want
to get out to users but also gives users some guarantee of when to expect
a new release.
Now there may be times when we can't meet the target because we have less
time to devote to the project, larger refactors/new features may require
more significant testing and hardening periods etc. but it might be nice
for us to aim to do this.
Yes - a good discussion to have including what the general release
criteria are.
Also, I thought the community testing of SDB went rather well. Calling
a release, getting reports before having to freeze for the vote is a
good thing. We can keep the vote to 3 days. A long vote seems to gain
us little.
In past life the target was once every 6 months but that was for the
more stable bit. As we need to start removing old stuff (e.g. DAML+OIL,
bulk update handlers, ...)
Maybe 3? 4? months?
But it can be too frequent. Many users will not be upgrading each time
(not unreasonably).
It's becoming like Ubuntu LTS and normal releases.
What works for Cray?
We won't always make it - that's for sure. It's a tricky balance to
even mention plans because if you meet the tick point a couple of times
it becomes "expected" :-) Open source projects just seem to have demand
exceeding supply.
I suggested a 2.7.4 release now to sync with SDB ... thoughts? My worry
there was consuming PMC and interested parties bandwidth (I'd have added
LARQ as well as it is incubator'ed but it adds work for us all).
Andy
Rob
On 10/4/12 12:19 PM, "Andy Seaborne" <[email protected]> wrote:
