[libvirt] Schedule of next release

I just looked and we are at 142 patches since the 0.9.12 release. If we were to keep the 1 month between releases schedule we would need to enter freeze at the end of the week, and that mean a relatively small release next. So I suggests to delay the release by 2 more weeks which also has the advantage to get back to the end of the month deadline which is easy to remember. So unless there is a pressing issue to make a release soon which I don't know about, let's plan to enter freeze around Jun 22 for a release at the end of month. As a note it seems that the rate of changes to libvirt is decreasing a bit (see http://veillard.com/commits_by_year_month.png which I generated at the end of may with gitstats) so maybe we should start planning for slighty longuer release cycles. Let's see how the trend evolves, but I doubt the rate wil increase over the summer :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/

On 05.06.2012 16:04, Daniel Veillard wrote:
I just looked and we are at 142 patches since the 0.9.12 release. If we were to keep the 1 month between releases schedule we would need to enter freeze at the end of the week, and that mean a relatively small release next. So I suggests to delay the release by 2 more weeks which also has the advantage to get back to the end of the month deadline which is easy to remember. So unless there is a pressing issue to make a release soon which I don't know about, let's plan to enter freeze around Jun 22 for a release at the end of month.
As a note it seems that the rate of changes to libvirt is decreasing a bit (see http://veillard.com/commits_by_year_month.png which I generated at the end of may with gitstats) so maybe we should start planning for slighty longuer release cycles. Let's see how the trend evolves, but I doubt the rate wil increase over the summer :-)
Daniel
In fact, I am glad since it gives more time to test the new RPC changes I've just commited. Please, please - give it some testing. Anybody - since it's feature that everybody uses. Michal
participants (2)
-
Daniel Veillard
-
Michal Privoznik