If we are only considering about storm-kafka-client, I'd rather not decouple and consider shorter release cycle for Storm itself, since storm-kafka-client 1.2.0 looks pretty stabilized. (That's more alike retrospect, like if we were doing it in 1.0.0 or even before 1.1.0.)
Now storm-kafka-client is implicitly considered to support as a first class, and once we are supporting it as first class, fixing critical bugs in storm-kafka-client should trigger release, instead of waiting for Storm core to have some fixes to be worth to release. We should be able to bring multiple releases even in a month if we have critical/blocker, but we couldn't. (Storm 1.1.2 was ready to release some months ago, but waited for 1.2.0 to be ready.) That may be coupled with this issue. Btw, my idea mainly includes unmaintained connectors. We have 19 connectors, and for me several questions are brought. - Do we ensure they're all maintained? -- Did we exclude inactive committers/PMCs for connector's committer sponsors, and do they have enough committer sponsors after that? - Do they all worth to keep maintaining in Storm main repository? -- Should we trigger release if we find and resolve critical/blocker issue from them? If not, why we allow to leave the thing which is in main repository as inconsistent state? Thanks, Jungtaek Lim (HeartSaVioR) 2018년 1월 30일 (화) 오전 6:59, P. Taylor Goetz <ptgo...@gmail.com>님이 작성: > > > On Jan 29, 2018, at 3:55 PM, Arun Mahadevan <ar...@apache.org> wrote: > > When you say storm-kafka-client-vX.X.X, is it going to be completely > independent of the Storm version and will work across Storm 1.0.x, 1.x and > 2.0 (future) storm releases? > > > > It would be completely independent in that it would be released separately > and not rely on “Storm proper”’s release schedule. As far as > forward/backward compatibility, I can imagine that compatibility might > diverge at which point we’d create/maintain some sort of compatibility > matrix. > > -Taylor >
