I'm fine with that as long we decide that API stability between 1.0 and 1.1 aren't critical. It is important for both Drill and Hive to be on top of Calcite proper. If we decide that we will be fairly static beyond 1.0, we need to make sure the Drill 1.0's API's needs are incorporated before pushing or we'll get into a situation where there will be a divergent fork of Calcite again, which will ultimately hurt the community.
If this is just to get a release, let's just release 0.9.5 or similar. There is no reason to release 1.0 and guarantee API stability just because Hive needs a release. On Wed, Jan 14, 2015 at 9:59 AM, Julian Hyde <[email protected]> wrote: > 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 > >> > >
