On 07/20/2011 08:51 AM, Hugh Brock wrote:
On Wed, Jul 20, 2011 at 12:20:43PM +0100, Mark McLoughlin wrote:
On Tue, 2011-07-19 at 14:11 -0400, Hugh Brock wrote:
Hello all.
With release 0.3.0 about ready to ship it seems like a good time to start talking about features we'd like to see for 0.4.0. I'd like to continue the three-month release cycle we've been on, so that puts our next one around mid-October.
You know, looking at this list, I really wonder - why not release earlier and oftener?
we don't have a massive amount of sub-projects; we should be able to turn around a release very quickly and the more often we do it, the smoother the process will be
we're not intentionally breaking anything on a regular basis, so there shouldn't be any reason not to release more often
shorter release cycles means the goals for each cycle won't be as far reaching and hand-wavey, instead it would be a much more specific set of tasks and features
Why not aim for e.g. every 3 weeks? Or perhaps every 2 weeks?
I have no problem with releasing more often, as long as we do that without incurring the overhead of a full QE cycle. If people will be happy with a minor/major type of release setup where we do frequent releases but only do a really solid release once every 3 months or so, I see no problem with that.
+1
That's one of the things that Chris was getting at with establishing testing vs 0.x.0 type repos so that the community has a fairly obvious way to differentiate between firmed up releases vs 'hot off the presses' type stuff.
One thing to consider is whether the publishing of rpms should fall within whatever period is decided on. I'd vote for 3 weeks simply because I know a few other projects are aligning against 3 weeks and I'd hate to cause more churn there. I'd also vote that we include the building/publishing of the rpms in the release cycle itself simply so that each chunk of time is self-contained.
<lots of good info snipped>
Mike