Folks, please take a look at this. We need to decide the schedule for 4.6.0.
- Sijie On Mon, Aug 7, 2017 at 6:59 PM, Sijie Guo <guosi...@gmail.com> wrote: > Hi all, > > First thanks everyone who contributed to 4.5.0 in the past year, and > especially thanks JV for spending time doing the release. The first release > candidate of 4.5.0 is finally out of review now. We are almost there. > > We eventually merge the major features from 3 main folked branches > (Salesforce, Twitter and Yahoo), so that we can converge to one main open > source branch across different organizations. We added a lot of features, > bug fixes and improvements. We moved to github to make contribution easier > and friendly and we have new website with more documentation. There are > tons of works we did very well in 4.5.0. > > However, I think the release has taken too long to complete. It causes a > lot of inconsistencies between code, configuration and documentation. This > causes most of the contributions were spent on improving documentation at > the end of the release. And also people can't really follow what's > happening in a long-cycle release and they eventually left. > > I am thinking of changing the release plan/schedule to a more time-based > mechanism what other projects (like Kafka, Flink) are doing: > https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan > Some of the benefits are documented in their wikis (also copied them in > the email for easy to read). > > Any thoughts? Shall we try to adopt this method? > > > 1. > > A quicker feedback cycle and users can benefit from features shipped > quicker > 2. > > Predictability for contributors and users: > 1. > > Developers and reviewers can decide in advance what release they > are aiming for with specific features. > 2. > > If a feature misses a release we have a good idea of when it will > show up. > 3. > > Users know when to expect their features > 3. > > Transparency - There will be a published cut-off date (AKA feature > freeze) for the release and people will know about it in advance. Hopefully > this will remove the contention around which features make it. > 4. > > Quality - we've seen issues pop up in release candidates due to > last-minute features that didn't have proper time to bake in. More time > between feature freeze and release will let us test more, document more and > resolve more issues. > > > - Sijie >
