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
