Let me start with a version "2+" tag and at least write in the description that it's only for issues that are clearly to be fixed, but must wait until 2.x.
On Thu, Feb 12, 2015 at 8:54 AM, Patrick Wendell <pwend...@gmail.com> wrote: > Yeah my preferred is also having a more open ended "2+" for issues > that are clearly desirable but blocked by compatibility concerns. > > What I would really want to avoid is major feature proposals sitting > around in our JIRA and tagged under some 2.X version. IMO JIRA isn't > the place for thoughts about very-long-term things. When we get these, > I'd be include to either close them as "won't fix" or "later". > > On Thu, Feb 12, 2015 at 12:47 AM, Reynold Xin <r...@databricks.com> wrote: >> 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 <so...@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-unsubscr...@spark.apache.org >>> For additional commands, e-mail: dev-h...@spark.apache.org >>> >>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
