0.15 release date changes

[Alexander Belchenko]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel пишет:
> 
> There are other mental overheads of having a freeze week, etc.
> 
> It ends up that 4-weeks is probably a little too fast. We've also come
> close to getting real regressions because of the last-week's "let's get
> this merged before we freeze".
> 
> So I might actually recommend extending the freeze cycle to be 2-weeks.
> 1 with frozen features, and 1 with only regression fixes (I guess that
> was supposed to be the rc week, but I'm not sure if that is really
> working as expected).
> 
> I also think it might be good to switch to a 6-week release cycle.


I think we could transform feature freeze week into bug hunting and
documentation improvements week. So 3 weeks of development,
then 1 week no new features (no new merge-requests) but only bug fixing,
then make branch for new release and produce rc1.
1 week for testing rc1 and providing fixes for known regressions if any.
Then rc2 and again 1 week before release.
We have 6 weeks. In another 2 weeks we could produce sub-release (e.g. 0.15.1)
if any regression found.

But because of conveyor 2 weeks of rc1/rc2 will overlaps with usual development.
With this schedule we could make release each months without freeze of bzr.dev.

But some new features need many times for discussing and reworking,
so adding another 1-2 week for development and get 6 weeks between releases
looks reasonable. Although I think that 8 weeks (2 months) is better.

(BTW, 0.14.1 is discussed but is not released).

- --
Alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFFyj/yzYr338mxwCURArRbAJ9jHFtq/MDJtkNLjZCsp/iCklQEaACYl0uM
fhei7IAtrz+uHXw89eiEiA==
=GZ6h
-----END PGP SIGNATURE-----