Re: [BuildStream] bst CLI design and consistency (UI)

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

On Tue, 2018-12-04 at 09:17 +0000, Daniel Silverstone via BuildStream-list wrote:
> On Tue, Dec 04, 2018 at 08:23:25 +0100, Jürg Billeter wrote:
[...]
> > Transition
> > ----------
> >
> > I'm also wondering whether we should help existing users a bit and
> > provide a nicer experience than just, e.g., 'Error: No such command
> > "track"'. We could keep the old top-level names as aliases with a
> > deprecation warning, or at least provide an error message with the new
> > command name.
> >
> > Don't know whether that would be straight forward with Click. E.g., we
> > probably want to remove the old commands in any case from the top-level 
> > help.
>
> In a general sense, IMO, it's best to:
>
> 1. provide new UI
> 2. make old UI warn and then use new UI (if possible)
> 3. make old UI error and explain what to do to use new UI
> 4. drop old UI
>
> Ideally 1 and 2 happen in release A, 3 in A+1, and 4 in A+2
> (where +1 and +2 don't have to be singular release cycles)

I very much dislike putting any such policy in place, as it looks like
we are making a promise to constantly break things over time.

It would be nice in this case to keep compatibility for the older
semantics temporarily but frankly I consider this just "nice to have",
and would be fine with only addressing this in a porting guide /
documentation.

While I do agree with Paul's adjacent reply here that breaking the
command line for us is much less of a concern than breaking format
compatibility, I think this is a temporary situation due to our tool
being relatively young (I'm sure that we would all be pretty upset if
the git developers were to bikeshed their CLI even once let alone
multiple times, given the amount of scripting which exists in the wild
and depends on the git CLI).

My view on this remains: Lets make a hard break once because apparently
most of the contributors want this, and lets try to never do it again,
with a great measure of consideration if we ever do break the CLI in
the future (i.e. we might break one thing here or there again one day,
less drastically, and only perhaps a new command which doesn't effect
many users).

I'd like to also underline that our motivations for remaining stable in
the long term should be a matter of dignity, it is what makes the tool
trustworthy for the new users we want to attract - in other words: the
volume of existing users should not be the motivating factor in being
stable.

Cheers,
    -Tristan