Hi,
Your arguments are actually supporting more the time-based cycles :).
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).
Let me know if I missed some your points or if my thinking is wrong.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 11/26/2012 04:02 PM, Jeff Pyle wrote:
On Sun, Nov 25, 2012 at 10:32 AM, Brett Nemeroff <br...@nemeroff.com
<mailto:br...@nemeroff.com>> wrote:
Just my two cents here...
With regards to the release cycle... I typically find myself doing
"production" deployments for my clients. What I need is a stable
version. And then hotfixes as bugs are discovered.
I prefer feature driven releases because I can look forward to
when feature X will be available. My production deployments
typically run untouched while in production mode. Upgrades occur
when new features are needed AND available in stable builds. I
don't typically upgrade simply because an upgrade is available. Of
course, I'll normally upgrade for critical fixes or security fixes
(which I'd see as a hotfix typically and not a full release)
If I knew a release was going to be available on a particular
date, I would without question start reviewing that release and
it's new capabilities; but I wouldn't need it for a production build.
If I knew a feature was available on a certain date, I could pitch
that to my clients if it was a feature they might need. Also, I'm
afraid that time based releases may rush features out before they
are ready.
That's just my perspective based on my workflow. I'm sure there
are others that feel differently. :)
-Brett
I, for one, share Brett's perspective.
- Jeff
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
