Mailing-List: contact dev-help@spark.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: error (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: 
 <CAMAsSdJBY+YgnGD__q2QEAA-gi=VL_KHqvryxVBLJ1-Lg1pJ5g@mail.gmail.com>
References: 
 <CAMAsSdJBY+YgnGD__q2QEAA-gi=VL_KHqvryxVBLJ1-Lg1pJ5g@mail.gmail.com>
From: Reynold Xin <rxin@databricks.com>
Date: Thu, 12 Feb 2015 00:47:16 -0800
Message-ID: 
 <CAPh_B=Y2fv2EYN8Pb27W1YKDkdCM-DRrPEZagiDw80Cy21_tZQ@mail.gmail.com>
Subject: Re: How to track issues that must wait for Spark 2.x in JIRA?
To: Sean Owen <sowen@cloudera.com>
Cc: dev <dev@spark.apache.org>
Content-Type: multipart/alternative; boundary=001a11c135def24862050ee02b56

--001a11c135def24862050ee02b56
Content-Type: text/plain; charset=UTF-8

It seems to me having a version that is 2+ is good for that? Once we move
to 2.0, we can retag those that are not going to be fixed in 2.0 as 2.0.1
or 2.1.0 .

On Thu, Feb 12, 2015 at 12:42 AM, Sean Owen <sowen@cloudera.com> wrote:

> Patrick and I were chatting about how to handle several issues which
> clearly need a fix, and are easy, but can't be implemented until a
> next major release like Spark 2.x since it would change APIs.
> Examples:
>
> https://issues.apache.org/jira/browse/SPARK-3266
> https://issues.apache.org/jira/browse/SPARK-3369
> https://issues.apache.org/jira/browse/SPARK-4819
>
> We could simply make version 2.0.0 in JIRA. Although straightforward,
> it might imply that release planning has begun for 2.0.0.
>
> The version could be called "2+" for now to better indicate its status.
>
> There is also a "Later" JIRA resolution. Although resolving the above
> seems a little wrong, it might be reasonable if we're sure to revisit
> "Later", well, at some well defined later. The three issues above risk
> getting lost in the shuffle.
>
> We also wondered whether using "Later" is good or bad. It takes items
> off the radar that aren't going to be acted on anytime soon -- and
> there are lots of those right now. It might send a message that these
> will be revisited when they are even less likely to if resolved.
>
> Any opinions?
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@spark.apache.org
> For additional commands, e-mail: dev-help@spark.apache.org
>
>

--001a11c135def24862050ee02b56--