> > For other tickets you mentioned above like KAFKA-1013/1784, although 1013 > is a sub-task of 1000, it is not necessarily be part of 0.8.2.0 as its > parent ticket, which I think is OK since 0.8.2.0 is not a major version > release but a feature release. This is also reflected in the ticket itself > whose fixed version is set to blank. Similar to KAFKA-1328, which we > intentionally include into 0.8.2.0 to collect people's feedback on the > interface design.
My mistake, KAFKA-1013 was not marked as resolved in 0.8.2. However, 1784 was marked as both fixVersion=0.8.2 and Resolved, despite the fact that it was a duplicate of 1013, which I believe lead to its inclusion in the Changelog and my confusion. KAFKA-1328 I understand that it makes sense to solicit feedback on the new API, and it helps to have it in actual java/javadoc form for people to code against, but it kind of stings to read the changelog and get your hopes up for a new consumer only to read the code and find that it is unimplemented. I wonder how many people use open source packages and treat them as more or less black boxes, and don't actually read the implementations of every API they code against? I expect it's some large number... maybe not for a project of Kafka's young age, I'm not sure. Thank you very much for reading and responding! --Ian > On May 21, 2015, at 12:19 AM, Guozhang Wang <wangg...@gmail.com> wrote: > > Hi Ian, > > Thanks for the email. > > Whenever we decided to cut a new release of Kafka one of the committers > will go through all the tickets with fix version tagged to the release > version and make sure they are all resolved. For some cover-story tickets > like KAFKA-1000, I agree that we did not handle it correctly while > including the ticket into the release, and we should pay more attention to > them. > > For other tickets you mentioned above like KAFKA-1013/1784, although 1013 > is a sub-task of 1000, it is not necessarily be part of 0.8.2.0 as its > parent ticket, which I think is OK since 0.8.2.0 is not a major version > release but a feature release. This is also reflected in the ticket itself > whose fixed version is set to blank. Similar to KAFKA-1328, which we > intentionally include into 0.8.2.0 to collect people's feedback on the > interface design. > > I think one thing we can do moving forward is to have some guiding > conventions for which types of tickets should be included in major / > feature / bug-fix releases, ASF has some general compatibility rules for > versions (https://apr.apache.org/versioning.html), but that is all I can > find. > > Guozhang > > > On Wed, May 20, 2015 at 4:07 PM, Ian Friedman <i...@flurry.com> wrote: > >> Hey guys, been a while since I sent a message to this list. I have not >> been following Kafka development closely for the past 9 or so months, but >> I'm now evaluating upgrading our installation to Kafka 0.8.2 and wanted to >> share my experiences in attempting to get a handle on that. >> >> First thing I did was check the changelog, easily found here: >> https://archive.apache.org/dist/kafka/0.8.2.0/RELEASE_NOTES.html >> >> I started going through that, clicking on things relevant to my interests >> as of the last release, assuming anything in that list would be an >> implemented fix or new feature, but what I found was that many Jiras are >> misleading either with respect to their fix version, their actual status, >> or their contents. >> >> Examples: >> >> https://issues.apache.org/jira/browse/KAFKA-1000 - fix version is a >> released version but ticket is still open >> https://issues.apache.org/jira/browse/KAFKA-1784 - has fix version but >> marked as duplicate of a still open ticket >> https://issues.apache.org/jira/browse/KAFKA-1013 - similarly, marked as >> fixed in 0.8.2.0 but still open and seemingly not merged into the 0.8.2.0 >> branch >> https://issues.apache.org/jira/browse/KAFKA-1328 - Including an >> unimplemented API into a release? >> >> All in all, based on these few initial findings, I found myself quickly >> distrusting the changelog list and the Jiras marked with the 0.8.2.0 tag, >> so that turned into a very hard time digging through the jiras and git repo >> to see what actually changed between versions. It seems to me like if a >> jira is marked as fixed in a released version, then it should actually be >> fixed in that version, and if not the fixVersion tag should be removed >> until it is, so it doesn't show up in searches/misleading changelogs. >> >> Anyway, just my two cents, thank you for reading. >> >> --Ian >> >> > > > -- > -- Guozhang
