Perhaps a more formal date driven (or major feature driven) could be introduced once an stable initial 1.0.0 is released. I don’t know that a date-driven release policy makes sense, at least not yet, and less likely for Major versions. I can see the benefit for more predictable Minor and Patch updates.
Where version numbers are MAJOR.MINOR.PATCH, and we increment the: 1. MAJOR version when we make incompatible API changes, 2. MINOR version when we add functionality in a backwards-compatible manner, and 3. PATCH version when we make backwards-compatible bug fixes. It would seem to make sense that PATCH releases occur as frequently as possible (as soon as they are available). It would make sense to release MINOR versions regularly, perhaps adding a very limited scope of new functionality to keep releases coming more frequently, versus long drawn out development cycles. MAJOR releases could be driven by date or roadmap driven based only on the need to introduce breaking API changes. Committing to MAJOR version releases every 3 months seems unmanageable, since you would be breaking backwards compatibility every 3 months. How about a regular MINOR / PATCH release schedule? Schedule (and warn the community) about MAJOR updates when it warrants a breaking change, but make this less frequent and more roadmap driven. Jeff On 3/4/16, 7:47 AM, "moon soo Lee" <m...@apache.org> wrote: >Hi folks, > >Zeppelin project used made releases driven by feature. >I'm getting constant feedback from users about moving to date-driven >release policy from current feature-driven. (such as major release every 3 >months) > >They have pros and cons. The question is, which policy is better for users >and developers of this project? > >One good thing about date driven approach i think is, Zeppelin usually gets >a lot of contributions not in the release scope. Date driven policy can >give user expectation of availability of those contributions. > >What do you think? Can you share your experiences and opinions? > >Thanks, >moon
