Versioning

[Gino Bustelo <gi...@bustelos.com>]

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

Re: Versioning

[Corey Stubbs <ca...@gmail.com>]

+1 on restarting the version number.

On Fri, Jan 8, 2016 at 11:32 AM Chip Senkbeil <ch...@gmail.com>
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 <gi...@bustelos.com> 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
> >
>

Re: Versioning

[Chip Senkbeil <ch...@gmail.com>]

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 <gi...@bustelos.com> 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
>