It does make sense for each spout has its own version number. We should
define a guide about the versions and a good way to track them.
For Heron version, it is a good question. Spouts are not that dependent on
Heron version so I feel the lib shouldn't need to have this dependency.
However we may
As an analogy I was looking at Hadoop, yarn and spark as a comparison related
to get some ideas and it seems that these components work together pretty
seamlessly and have independent versioning. I really feel like it’s up to the
main engineers of each spout project on how to version things,
This is a good question. Each version spout must maintain a compatibility
matrix {Spout Version, external SDK version, Heron API version}. It’s more
of a documentation effort so that user haves enough information to
determine which one to pick, isn’t it?
On Thu, Jan 17, 2019 at 7:48 AM Josh
As long as it does not have to be a single release train for all of the
spout, I’m good with a single separate repo hosting all of spout. We just
need a bit upfront effort to setup Bazel for the project.
However, I expect once one Spout project folder is setup, it can serve as
sample for other
