Jeff makes a good point - the project still needs to get to a 1.0 release.
The definition of a 1.0 release would seem to be feature/testing-based. Perhaps the priority should be defining, and then completing, 1.0. Then if there's still demand, the project could switch to calendar-based for periodic updates. Is there really a lot of desire for this anyway? I don't think there has been any correspondence on the user mailing list requesting calendar updates at all. > On Mar 4, 2016, at 11:57 AM, Jeff Steinmetz <jeffrey.steinm...@gmail.com> > wrote: > > > 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 >
