[lots of snippage below] On Tue, May 15, 2012 at 9:59 AM, Robert Schweikert <rjsch...@suse.com> wrote: > A release a month does not work for packagers. With CloudStack code being > open source it can be included in distributions. If there is a release every > month packagers will quickly feel like they are chasing their own tail and > thus give up. Other cloud platforms appear to sustain their momentum with a > timed release cycle of a bout 6 month. This is a reasonable time period for > packagers of a comunity distribution. > > I think one needs to think about the long term goal first. for this there > are only two models, either feature based releases (release date floats) or > time based releases (no "guaranteed" features). Many projects do well with > time based releases. With a release cycle of 6 month it is not really that > tragic if a particular feature misses a given release as it will be in the > next release (if it's ready) that is only 6 month away.
I agree, and personally feel very strongly that we should be targeting a time-based release. I don't know if I like the 6 month cycle - 3 or 4 given the rate of innovation in the field seems a little more manageable. At the same time, maybe X.Y (as defined below) is what happens on those release cycles and we permit X.Y.Z+1 more frequently but constrained to bug fix only releases. > > The key to time based releases is to hit he "promised" date. Time based > releases where the date slips all the time are not in fact time based and > people loose interest as the project is seen as unreliable. This is exactly why I feel strongly about time-based releases. And even in time-based releases there can be slips, but nothing near the level that we see with feature-based releases. This positively sets the expectations among users around when to expect something new, it affirmatively sets the schedule/plan with contributors, so everyone can know exactly what is going on and when, how much time they have left to work on issues, etc. > > My suggestion would be to go with a 6 month time based release cycle and > also decide on a version numbering scheme. > > X.Y.Z > > - X : increases when there is a "major" change in architecture or some major > new feature > - Y : increases with every release every 6 month (reset when X increases) > - Z : increases when there are "must fix bugs" or annoying bugs that get > fixed in a release branch (reset when Y increases) Wholeheartedly agree with the above versioning logic. > > I think it would be reasonable to make a list of what needs to be done to > get a community release out the door and then put a stake in the ground and > say "we will be done on XXXXX". Count this as the first release and then > switch to the time based model. What Citrix does in between is should not > really have an effect. Of course it will on timing as initially there is > probably a lot of work required by Citris contributors to get processes, > testing etc. moved toward the community. > What do we think is a reasonable time to get a release out? 3 months? 4 months? 6 months? Lets find where we need to place the stake and do so soon. --David
