On Wed, Jan 4, 2017 at 2:02 PM, Olaf Flebbe <[email protected]> wrote: > 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.
Exactly! Thanks, Roman.
