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
