Hey,
This is fine, but even if you intro a new component's version with a version
appended to its name, you're still on the hook to make a decision of what
to use in some dependencie's do-component-build script. And that, what
I think needs to be, a default <component name> (no version as part of
the name).
Romans Word
#1 our implicit bias is to NOT have multiple version of
the same component in a stack?
seems central to me: A focus point of our project is integration of big
data components, favourably Apache components.
With a major upgrade we did something which is supposed to fail: We
force component from 1.x to 2.y. If the dev is using semantic versioning
this surely will fail. That happened with Spark, since we (That's me,
for instance) didn't realize that Spark is used deeply integrated by
that many other frameworks.
Argueing about COMPONENT_VERSION vs COMPONENT2_VERSION does not help
here: Big Data Community is split about how to handle Spark:
Apache Spark has created an own ecosystem around it. As far I can see,
anyone interested in Spark will use Spark2, anyone running traditional
workloads will run Spark1. We cannot fix this right now, so it is that way.
My proposed workaround is having Spark1 hanging unsupported around. This
can work out for both.
Olaf
