e 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
h 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; gene
ot 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 <r...@databricks.com> wrote:
>> > tl;dr
>> >
>> > I
se,
>> 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 <r...@databricks.com> wrote:
>> > tl;dr
>> >
&
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 <r...@databricks.com
>
g features
>
> On Thu, Jul 28, 2016 at 3:46 PM, Reynold Xin <r...@databricks.com> wrote:
> > tl;dr
> >
> > I would like to propose renaming “minor release” to “feature release” in
> > Apache Spark.
> >
> >
> > details
> >
> > Apache Spark’s officia
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].[mino
*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
