Hi Bogdan, > copying from another answer of mine: Keep in mind that all the time a new > release will be a set of new features, so basically all releases are also > featured driven. But to make it more predictable, we consider some time > limits (for a release cycle) - limits are quite large 5 to 7 months, so we > have flexibility to fit various sets of features in that interval. The main > idea with time-based cycles is to try to control how long will take for have > the next release (more predictable, without large gaps between releases) and > also to speed up the features delivery (having a faster cycle, features will > be available in stable versions quicker).
Ok, so it's more of a hybrid thing. In that case I'd be k with it, if we allow for some flexibility in case we were a bit too optimistic with the planning ;-) [snip] > > again, copying from another answer of mine: I have to admit I didn't do the > math - 2 release ~= 1 year, which indeed is too short - I mean this will > force an upgrade each year. So, we need to somehow get to ~ 2 year lifetime > for a release. My suggestion is to actually set a life span for 2 years. > 2 years sounds about right. Thanks for doing this in the Open, Bogdan :-) Kind regards, -- Saúl Ibarra Corretgé AG Projects _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
