Kern Sibbald <k...@sibbald.com> writes: > 2. New release cycle: > The little code we currently have for the next major release is in the > SF bacula git repository under Branch-5.1. > > We are considering to moving to a regular 6 month release cycle. The > advantage of such a cycle is that it gets features out to you faster. The > disadvantage is that it doesn't work so well in small projects like Bacula if > there > are not sufficient contributions. > > Such a release would consist of the following points: > > - A release every 6 months > - The deadline is not absolute and could be extended to 9 months if there were > insufficient new submissions. > - There will be far fewer or no bug fix updates as they are not really needed > if we can maintain a 6 month cycle.
It seems to me that 6-month cycle is ok for new features (maybe it's too short and 9-12 month cycle will be better), but it's too long for bugfixes. Maybe it would be better to separate this things (I'm not insisting, of course), e.g. New major release with new features: every 9-12 months New minor release with bugfixes only: every month (if needed). The disadvantage is: it's required to separate git branches for bugfixes and features (minor/major). This approach only matters if there will be enough bugfixes and new features for the community branches. -- Vitaly Kuznetsov, ALT Linux ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
