Hey Harsha, I noticed that you proposed that Storm should drop support for Java 7 in master:
http://markmail.org/message/25do6wd3a6g7cwpe It's useful to know what other Apache projects are doing in this regard, so I'm interested in the timeline being proposed for Storm's transition. I could not find it in the thread above, so I'd appreciate it if you could clarify it for us (and sorry if I missed it). Thanks, Ismael On Mon, Jun 20, 2016 at 5:05 AM, Harsha <ka...@harsha.io> wrote: > Hi Ismael, > Agree on timing is more important. If we give enough heads > up to the users who are on Java 7 thats great but still > shipping this in 0.10.x line is won't be good as it still > perceived as maint release even the release might contain > lot of features . If we can make this as part of 0.11 and > cutting 0.10.1 features moving to 0.11 and giving rough > timeline when that would be released would be ideal. > > Thanks, > Harsha > > On Fri, Jun 17, 2016, at 11:13 AM, Ismael Juma wrote: > > Hi Harsha, > > > > Comments below. > > > > On Fri, Jun 17, 2016 at 7:48 PM, Harsha <ka...@harsha.io> wrote: > > > > > Hi Ismael, > > > "Are you saying that you are aware of many Kafka users still > > > using Java 7 > > > > who would be ready to upgrade to the next Kafka feature release > (whatever > > > > that version number is) before they can upgrade to Java 8?" > > > I know there quite few users who are still on java 7 > > > > > > This is good to know. > > > > > > > and regarding the > > > upgrade we can't say Yes or no. Its upto the user discretion when they > > > choose to upgrade and ofcourse if there are any critical fixes that > > > might go into the release. We shouldn't be restricting their upgrade > > > path just because we removed Java 7 support. > > > > > > > My point is that both paths have their pros and cons and we need to weigh > > them up. If some users are slow to upgrade the Java version (Java 7 has > > been EOL'd for over a year), there's a good chance that they are slow to > > upgrade Kafka too. And if that is the case (and it may not be), then > > holding up improvements for the ones who actually do upgrade may be the > > wrong call. To be clear, I am still in listening mode and I haven't made > > up > > my mind on the subject. > > > > Once we released 0.9.0 there aren't any 0.8.x releases. i.e we don't > > > have LTS type release where we continually ship critical fixes over > > > 0.8.x minor releases. So if a user notices a critical fix the only > > > option today is to upgrade to next version where that fix is shipped. > > > > > > > We haven't done a great job at this in the past, but there is no decision > > that once a new major release is out, we don't do patch releases for the > > previous major release. In fact, we have been collecting critical fixes > > in > > the 0.9.0 branch for a potential 0.9.0.2. > > > > I understand there is no decision made yet but given the premise was to > > > ship this in 0.10.x , possibly 0.10.1 which I don't agree with. In > > > general against shipping this in 0.10.x version. Removing Java 7 > support > > > when the release is minor in general not a good idea to users. > > > > > > > Sorry if I didn't communicate this properly. I simply meant the next > > feature release. I used 0.10.1.0 as an example, but it could also be > > 0.11.0.0 if that turns out to be the next release. A discussion on that > > will probably take place once the scope is clear. Personally, I think the > > timing is more important the the version number, but it seems like some > > people disagree. > > > > Ismael >
