+1 for adopting a 1 month release cycle. --
Mike Dusenberry GitHub: github.com/dusenberrymw LinkedIn: linkedin.com/in/mikedusenberry Sent from my iPhone. > On Jan 5, 2017, at 1:35 PM, Luciano Resende <luckbr1...@gmail.com> wrote: > > On Thu, Jan 5, 2017 at 6:05 AM, Matthias Boehm <mboe...@googlemail.com> > wrote: > >> In general, I like the idea of aiming for consistent release cycles. >> However, every month is just too much, at least for me. There is a >> considerable overhead associated with each release for end-to-end >> performance tests, tests on different environments, code freeze for new >> features, etc. Hence, a too short release cycle would not be "agile" but >> would actually slow us down. From my perspective, a realistic release >> cadence would be 2-3 months, maybe a bit more for major releases. >> >> > 2-3 months of release cadence for an open source is probably a long > stretch, particular for a project that does not have very large set of 3rd > party dependencies. > > As for some of the overhead issues you mentioned, they are probably easy to > workaround: > > - code-freeze timeframe can be resolved with branches > - end-to-end performance regressions can be avoided by better code review, > and if you were willing to go with 2-3 months without performing these > tests, we could perform them only for major releases, and proactively > quickly build a minor release with the patch when a user report any > performance regression. > > > Anyway, I would really like to see SystemML more agile with regards to its > release process because, as I mentioned before, the release early, release > often mantra is good to increase community interest, generate more traffic > to the list as developers discuss the roadmap and release blockers, and > also enable users to provide feedback sooner on the areas we are developing. > > > > -- > Luciano Resende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/
