Yeah, you could, but 1. People will start calling it “Drill 10” (cf Hive and - ugh - HBase)
2. You will inevitably discover bugs in people’s code for parsing version strings. Julian On Jul 24, 2014, at 10:30 AM, Timothy Chen <[email protected]> wrote: > I was under the impression we can always go to 0.10+ if we're not ready :) > > Tim > > On Thu, Jul 24, 2014 at 10:28 AM, Julian Hyde <[email protected]> wrote: >> +1 >> >> Optiq has been “approximately monthly”, and that seems to have worked well. >> We weren’t tied to a particular date, so we could use our discretion to slip >> a bit if making a release wasn’t convenient. >> >> Now Optiq faces a different crunch… the next release will be 0.9, so there >> will be an expectation that the release after that will be “the big one”, >> i.e. 1.0. If you’re on a “early and often” cycle, no release feels like “the >> big one”. Hopefully you will feel like you’re at 1.0 quality well before >> December. >> >> Julian >> >> On Jul 24, 2014, at 9:16 AM, Parth Chandra <[email protected]> wrote: >> >>> +1 for monthly releases. >>> We could follow the Ubuntu model and use the number of the month for the >>> minor version number . >>> 0.07 for July, 0.08 for Aug, etc. >>> >>> >>> >>> >>> On Thu, Jul 24, 2014 at 8:56 AM, Yash Sharma <[email protected]> wrote: >>> >>>> +1. Would really love to see a release. >>>> It would be great if we can have prioritized JIRA's - labelled with 0.4 and >>>> we can focus solely on those for this week. >>>> >>>> Peace, >>>> Yash >>>> >>>> >>>> On Thu, Jul 24, 2014 at 9:05 PM, Jacques Nadeau <[email protected]> >>>> wrote: >>>> >>>>> Hey Everybody, >>>>> >>>>> It has been too long since our last release. So much good stuff has been >>>>> done in master but we have no release with which people can experiment. >>>> We >>>>> need to do a better job of releasing early and often. I think the >>>> monthly >>>>> cycle that Optiq and Spark uses works very well and propose we move to >>>> that >>>>> model. >>>>> >>>>> To kick this off, I propose we do a release next week that is our first >>>>> development point release that supports distributed execution. There are >>>>> probably a dozen outstanding patches that would be good to get into this >>>>> release and I'd like to try to target those but ultimately time-bound the >>>>> release. >>>>> >>>>> With releasing comes a discussion of version numbers. While we initially >>>>> started out with a milestone versioning scheme, the feedback I've >>>> received >>>>> is that it doesn't fit what people expect. As such, I propose moving to >>>> a >>>>> more traditional point release scheme. >>>>> >>>>> I think that we're probably a month or so away from a good beta release >>>>> which I think would fairly be considered a 0.5 release. As such, I >>>> propose >>>>> that we release 0.4 next week and then increment each month, targeting a >>>>> 1.0 release towards the end of the year. >>>>> >>>>> In summary, my release proposal is to target something similar to: >>>>> July: 0.4 (dev preview) >>>>> August: 0.5 (beta) >>>>> September: 0.6 >>>>> Oct: 0.7 >>>>> ... >>>>> EOY: 1.0 (ga) >>>>> >>>>> I think this more frequent release will help users to understand what >>>> Drill >>>>> is all about and let them start to experiment with their workloads. This >>>>> should also drive additional community engagement and new contributions >>>>> which is what this is all about. >>>>> >>>>> thanks, >>>>> Jacques >>>>> >>>> >>
