We are behind on our commitment to release “monthly”. Our last release was over 2 months ago. Hive has incorporated our API changes (in 1.0.0-SNAPSHOT) in their trunk and cannot release on a snapshot release. So, yes, we need to release earlier than mid-February.
If Jinfeng’s changes don’t make the cut for 1.0 there will be a 1.1 shortly afterwards. Julian On Jan 13, 2015, at 7:45 PM, Jacques Nadeau <[email protected]> wrote: > Jinfeng is in the process of getting Drill back onto the master of > Calcite. He is working on this actively right now. (We'd fallen a bit > behind.) I imagine there would be a smattering of fixes that will come out > of this work and I'd love to get these incorporated. I'd love to have a > couple more weeks to get those in and start a 1.0 vote early February. > Anything in particular that would make targeting a few weeks later an > issue? > > thx, > Jacques > > On Tue, Jan 13, 2015 at 2:03 PM, Julian Hyde <[email protected]> wrote: > >> I do consider SQL changes to be API changes. These particular changes are >> backward compatible (no previous valid SQL would be broken by these >> changes) and therefore they could be introduced in a point release (say >> 1.1). >> >> Julian >> >> >> On Jan 13, 2015, at 1:49 PM, James Taylor <[email protected]> wrote: >> >> Would CALCITE-505 or CALCITE-495 be considered API changes? These >> would be good to get in sooner rather than later IMO. >> >> >> On Tue, Jan 13, 2015 at 1:42 PM, Julian Hyde <[email protected]> wrote: >> >> I think we are close to being able to release Calcite 1.0. >> >> Release 1.0 is always a "big deal”, but I don’t want to make a huge deal >> out of it. In the semantic versioning methodology [ http://semver.org/ ], >> there is an understanding that after 1.0, APIs only change in significant >> ways in major versions. Accordingly, we aimed to complete the >> re-organization of code into the org.apache.calcite namespace before 1.0. >> >> But let’s not wait until the product is “done” before we release 1.0. (A >> software project is never “done”.) I’d like to keep up our >> about-once-a-month release tempo. >> >> I have served as Release Manager [ >> http://www.apache.org/foundation/glossary.html#ReleaseManager ] on >> previous >> releases, but one of the things we need to achieve before we graduate from >> the Incubator is to spread the tasks among committers. Would someone else >> like to volunteer to be release manager? >> >> What issues must be fixed before 1.0? I only have two: >> >> >> - https://issues.apache.org/jira/browse/CALCITE-466 >> - https://issues.apache.org/jira/browse/CALCITE-558 >> >> >> Any others? >> >> What timeline for the release? How about if we create the first release >> candidate a week from today Tue 1/20? (It may take a few release >> candidates, then a 3 day vote, then a 3 day IPMC vote.) >> >> Please chime in on the release timescale, critical issues, and offers to >> help. >> >> Julian >>
