On Mon, Jan 2, 2017 at 5:53 PM, Konstantin Boudnik <[email protected]> wrote:
> I'd say there's nothing wrong with having newer versions of a component, even
> as a mere "preview" for the users who are wiling to take the risk of running
> something not yet stable/well polished.

Sure, but for some components (like HDFS, etc.) this means essentially
having different stacks. For some components like Pig it is easier of course
but the question still remains -- what's the default version in a
Bigtop's release.

> My concern is that the latest approach (which goes opposite to what has been
> done for Sqoop in the similar situation and went unnoticed because the 
> original
> version hasn't been touched) introduces a lot of hassle and breaks the build
> for an uncertain period of time. And it puts the pressure on the people
> involved and might lead to haphazard patches.

I think this goes back to my point of what's the majority opinion on what the
default is. For Spark it is 2, for Sqoop it was 1.

All I'm saying is that the happy path (with component not having a version
as part of its name) could be different in different cases, but it is up to us
to agree on what that happy path is.

Then, after we agree, all sort of other versions could be added to the stack
with <component><version> naming scheme.

What this signals to our user community is that as Bigtop maintainers we're
totally willing to support <component>, but things like  <component><version>
are "use at your own risk".

> As I have said before, let's introduce new versions under new name (like
> component2, component3, etc.) and keep the original 'component' intact until
> some later time. That seems to be a safe way of adding multiple versions and
> yet not to disrupt the stability of the stack. Clearly, even better approach
> is to do such work on the branch but it might put too much load on our CI,
> etc.

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).

Thanks,
Roman.

Reply via email to