Not sure if I will be able to attend. IMO, in major.minor.patch semantic versioning scheme (which I believe we're applying and want to adhere to), there is no frequency dimension, there's just scope dimension. There is nothing in versioning scheme preventing one to release even major version multiple times during a single day.
Scope of patch release is expected to include bugfixes, documentation and similar. It is also expected for a patch release to be backward compatible - one can without touching sources upgrade only version number of a dependency and have a previously buggy behavior now working as expected. If we define a new 0.10.1 release with such scope, I'm fine with it. So far scope for next release included backward incompatible changes, like artifact name changes, and major dependency changes (like spark 1.1.1 to spark 1.3.x) and more. That's why I proposed release with such scope to have minor version part incremented, from 0.10 to 0.11. I'm not sure but I doubt there's anything in Apache way of doing things, that's preventing us from having both 0.10.1 and 0.11.0 releases planned and worked on in parallel with dedicated branches e.g. master for next major.minor/non-bug-fix release, and branches for bug fix supported versions like 0.10 or 0.10.x. One can create a 0.10.x branch from 0.10.0 release tag. Changes there have to be regularly merged to master. When it comes to frequency for bug fix / patch releases I wouldn't mind if we released whenever a new bug fix (implementation or documentation) is resolved and reviewed. Kind regards, Stevo Slavic. On Tue, Apr 14, 2015 at 8:23 AM, Ted Dunning <ted.dunn...@gmail.com> wrote: > A word of warning about making decisions off-list and without a permanent > record on the mailing list. > > I will likely be available, but may not be. I am happy with whatever the > consensus is (with a tilt towards frequent releases), but would like to see > most of the decision process on the list. > > > On Tue, Apr 14, 2015 at 4:44 AM, Suneel Marthi <suneel.mar...@gmail.com> > wrote: > > > We should talk about this. Could the team "slack" tomorrow 1PM Eastern > Time > > to talk this out and also finalize scope for the next one? > > > > On Mon, Apr 13, 2015 at 9:14 PM, Dmitriy Lyubimov <dlie...@gmail.com> > > wrote: > > > > > i thought we wanted to do 0.10.1 with a quicker release cycle and > > bugfixes? > > > > > > On Sun, Apr 12, 2015 at 6:47 AM, Suneel Marthi < > suneel.mar...@gmail.com> > > > wrote: > > > > > > > On Sun, Apr 12, 2015 at 8:56 AM, Stevo Slavić <ssla...@gmail.com> > > wrote: > > > > > > > > > Hello team, > > > > > > > > > > Should next version be 0.10.1 or 0.11.0? > > > > > > > > > > > > > I am fine with just 0.11 > > > > > > > > > > > > > > > > > > Thinking maybe 0.11.0 is more suitable, if it's going to contain > > > artifact > > > > > name changes like MAHOUT-1680 and MAHOUT-1681, and fundamental new > > > > > features, so we keep minor releases for backward compatible bug fix > > > > > releases only. > > > > > > > > > > Btw, it would be good (whoever has privileges) to have versions in > > JIRA > > > > > project sorted out: > > > > > - mark 0.10.0 as released > > > > > - remove two empty 1.0-snapshot versions > > > > > - move 1.0 to the top and clear its release date > > > > > - move 0.10.1/0.11.0 under 1.0 and after 0.10.0 > > > > > > > > > > > > > Stevo, u should have permissions now to fix all of the above. > > > > > > > > > > > > > - maybe plan and set 0.10.1/0.11.0 expected release date (Suneel > was > > > > > mentioning it would be nice to integrate with Apache Flink by > October > > > > > timely for http://lanyrd.com/2015/flink-forward/ ) > > > > > > > > > > > > > This would definitely be a good story to present at > > > > http://lanyrd.com/2015/flink-forward/ > > > > > > > > The Flink team is ready to dedicate resources from their camp to work > > > with > > > > us. > > > > > > > > > > > > > Kind regards, > > > > > Stevo Slavic. > > > > > > > > > > > > > > >
