[bt-devel] Release Cycle Refinement

Eeli Kaikkonen eekaikko at mail.student.oulu.fi
Wed Nov 18 10:03:37 MST 2009


On Wed, 18 Nov 2009, Raoul Snyman wrote:

> After further discussion between Martin, Jaak and myself, we came to an
> agreement that the 2.4 and 2.5 releases would continue as scheduled, but that
> we'd try a 6 week cycle for 2.6.

You mean 8?

> What does everyone think about this? Any comments or suggestions?

I would have been willing to take 2-4 months between major (2.x)
releases. Maybe 4 months is too much, but 8 weeks is still quite short.

There should be at least one month between minor (2.x.x) releases so
that packagers and users have enough time to adopt them. Only if we find
and fix grave bugs we should release a minor with a shorter interval.

I also repeat my opinion about the meaning of RC: it's meant to be
tested by everyone, so it should have long life enough to get it to end
users via packagers. It means about 4 weeks. I know it's very long
compared to our current pace, but I don't see a way out of the problem.
If it's not going to be publicly available in practice, we can leave it
out altogether and just announce a couple of betas and try to find
the bugs ourselves (which we have been doing right now). Especially if
we allow bugfixes after the last RC. As I said, the last RC should be
released (almost) as is with a new version number. If there are many
changes, a new RC should be released with RCn+1 version number.

But I can be happy with the new consensus. Only the usage of "RC" name
against the common convention would remain as a complaint.

  Yours,
	Eeli Kaikkonen (Mr.), Oulu, Finland
	e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)



More information about the bt-devel mailing list