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.
+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:
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.
On Jul 24, 2014, at 9:16 AM, Parth Chandra <[EMAIL PROTECTED]> wrote:
+1 for monthly release. It's a good idea to use the similar approach as the other open source projects, and releasing monthly will make it easier for people in the community to try out Drill. On Thu, Jul 24, 2014 at 10:35 AM, Julian Hyde <[EMAIL PROTECTED]> wrote:
Sounds like positive support. I'll go through and tag a set of candidate issues. One of the things I'll add to jira is making sure our binary tarball passes muster as we hit a snag last time on that. I'll report back here with a list of potential Jiras people can pitch in on.
+1 ... it'll really expand the number of people using Drill, so we get good feedback on what's working and what's not. Glad that Drill is already sufficiently rich to allow complex use-cases, so the feedback should be first-class.
thanks & regards, Srivas.
*---* *M.C. Srivas, CTO & Co-founder, *MapR Technologies, Inc. <http://www.mapr.com> On Thu, Jul 24, 2014 at 8:35 AM, Jacques Nadeau <[EMAIL PROTECTED]> wrote:
+1 for frequent incremental releases. On Thu, Jul 24, 2014 at 10:33 PM, M. C. Srivas <[EMAIL PROTECTED]> wrote:
NEW: Monitor These Apps!
Apache Lucene, Apache Solr and all other Apache Software Foundation project and their respective logos are trademarks of the Apache Software Foundation.
Elasticsearch, Kibana, Logstash, and Beats are trademarks of Elasticsearch BV, registered in the U.S. and in other countries. This site and Sematext Group is in no way affiliated with Elasticsearch BV.
Service operated by Sematext