+1 on restarting the version number. On Fri, Jan 8, 2016 at 11:32 AM Chip Senkbeil <[email protected]> wrote:
> I agree with starting the version from scratch. Needing to keep Toree in > line with the Spark version is difficult and limits us to the revision > versions. > > Furthermore, now that we work as a Spark Submit application and use SPARK > HOME to identify the Apache Spark version to use, I don't see the need to > match our own version specifically with the Apache Spark version. > > Something we might need to consider when releasing binaries is that we need > to build the kernel against different Spark versions similar to how Apache > Spark provides binary distributions against different Hadoop distros. > > On Fri, Jan 8, 2016 at 11:28 AM Gino Bustelo <[email protected]> wrote: > > > I would like to start the discussion around versioning. As spark-kernel, > we > > were attempting to keep the version of the project consistent with the > > version of Spark. For example: > > > > Spark 1.6.0 comes out, Spark-Kernel 1.6.0 would get releases. > > > > Advantages: > > - Easy identify compatibility > > > > Disadvantages: > > - Hard to accommodate our own features and fixed. > > - Most of the time the same codebase supports multiple Spark versions > > > > For Toree, I propose we move start from scratch. > > > > Lets say we start from version 0.1.0. > > > > I'm assuming that during incubation we do not touch the MAJOR portion of > > the version. > > > > The MINOR portion of the version is updated when: > > - Enough features to put a new release > > - Changes due to new version of Spark that break backwards or uses new > > features > > > > The PATCH portion of the version is updated when: > > - Fixes and minor feature additions > > >
