Re: renaming "minor release" to "feature release"

[Reynold Xin <rx...@databricks.com>]

Yup that's a good point. I think we can easily explain that in the extended
description. I will update the wiki page to reflect that.


On Fri, Jul 29, 2016 at 7:52 AM, Mark Hamstra <ma...@clearstorydata.com>
wrote:

> One issue worth at least considering is that our minor releases usually do
> not include only new features, but also many bug-fixes -- at least some of
> which often do not get backported into the next patch-level release.
>  "Feature release" does not convey that information.
>
> On Thu, Jul 28, 2016 at 8:20 PM, vaquar khan <va...@gmail.com>
> wrote:
>
>> +1
>> Though following is commonly use standard for release(http://semver.org/)
>>  ,feature also looks good as Minor release indicate significant features
>> have been added
>>
>>    1. MAJOR version when you make incompatible API changes,
>>    2. MINOR version when you add functionality in a backwards-compatible
>>    manner, and
>>    3. PATCH version when you make backwards-compatible bug fixes.
>>
>>
>> Apart from verbiage "Minor" with "feature"  no other changes in
>>  versioning policy.
>>
>> regards,
>> Vaquar khan
>>
>> On Thu, Jul 28, 2016 at 6:20 PM, Matei Zaharia <ma...@gmail.com>
>> wrote:
>>
>>> I also agree with this given the way we develop stuff. We don't really
>>> want to move to possibly-API-breaking major releases super often, but we do
>>> have lots of large features that come out all the time, and our current
>>> name doesn't convey that.
>>>
>>> Matei
>>>
>>> On Jul 28, 2016, at 4:15 PM, Reynold Xin <rx...@databricks.com> wrote:
>>>
>>> Yea definitely. Those are consistent with what is defined here:
>>> https://cwiki.apache.org/confluence/display/SPARK/
>>> Spark+Versioning+Policy
>>>
>>> The only change I'm proposing is replacing "minor" with "feature".
>>>
>>>
>>> On Thu, Jul 28, 2016 at 4:10 PM, Sean Owen <so...@cloudera.com> wrote:
>>>
>>>> Although 'minor' is the standard term, the important thing is making
>>>> the nature of the release understood. 'feature release' seems OK to me
>>>> as an additional description.
>>>>
>>>> Is it worth agreeing on or stating a little more about the theory?
>>>>
>>>> patch release: backwards/forwards compatible within a minor release,
>>>> generally fixes only
>>>> minor/feature release: backwards compatible within a major release,
>>>> not forward; generally also includes new features
>>>> major release: not backwards compatible and may remove or change
>>>> existing features
>>>>
>>>> On Thu, Jul 28, 2016 at 3:46 PM, Reynold Xin <rx...@databricks.com>
>>>> wrote:
>>>> > tl;dr
>>>> >
>>>> > I would like to propose renaming “minor release” to “feature release”
>>>> in
>>>> > Apache Spark.
>>>> >
>>>> >
>>>> > details
>>>> >
>>>> > Apache Spark’s official versioning policy follows roughly semantic
>>>> > versioning. Each Spark release is versioned as
>>>> > [major].[minor].[maintenance]. That is to say, 1.0.0 and 2.0.0 are
>>>> both
>>>> > “major releases”, whereas “1.1.0” and “1.3.0” would be minor releases.
>>>> >
>>>> > I have gotten a lot of feedback from users that the word “minor” is
>>>> > confusing and does not accurately describes those releases. When
>>>> users hear
>>>> > the word “minor”, they think it is a small update that introduces
>>>> couple
>>>> > minor features and some bug fixes. But if you look at the history of
>>>> Spark
>>>> > 1.x, here are just a subset of large features added:
>>>> >
>>>> > Spark 1.1: sort-based shuffle, JDBC/ODBC server, new stats library,
>>>> 2-5X
>>>> > perf improvement for machine learning.
>>>> >
>>>> > Spark 1.2: HA for streaming, new network module, Python API for
>>>> streaming,
>>>> > ML pipelines, data source API.
>>>> >
>>>> > Spark 1.3: DataFrame API, Spark SQL graduate out of alpha, tons of new
>>>> > algorithms in machine learning.
>>>> >
>>>> > Spark 1.4: SparkR, Python 3 support, DAG viz, robust joins in SQL,
>>>> math
>>>> > functions, window functions, SQL analytic functions, Python API for
>>>> > pipelines.
>>>> >
>>>> > Spark 1.5: code generation, Project Tungsten
>>>> >
>>>> > Spark 1.6: automatic memory management, Dataset API, ML pipeline
>>>> persistence
>>>> >
>>>> >
>>>> > So while “minor” is an accurate depiction of the releases from an API
>>>> > compatibiility point of view, we are miscommunicating and doing Spark
>>>> a
>>>> > disservice by calling these releases “minor”. I would actually call
>>>> these
>>>> > releases “major”, but then it would be a larger deviation from
>>>> semantic
>>>> > versioning. I think calling these “feature releases” would be a
>>>> smaller
>>>> > change and a more accurate depiction of what they are.
>>>> >
>>>> > That said, I’m not attached to the name “feature” and am open to
>>>> > suggestions, as long as they don’t convey the notion of “minor”.
>>>> >
>>>> >
>>>>
>>>
>>>
>>>
>>
>>
>> --
>> Regards,
>> Vaquar Khan
>> +91 830-851-1500
>>
>>
>