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
It's young like pre-1.x :). Getting stable on the data format and cache keys early, would make life easier, as even with breakage in a CLI, versions would interoperate. As such you could test new versions, decide to downgrade, and not lose the builds that you did with either version.
(I'm sure that we would all be pretty upset if
the git developers were to bikeshed their CLI even once let alone
I think we can all agree that the world would have been a better place had that happened and introduced consistency.
multiple times, given the amount of scripting which exists in the wild
and depends on the git CLI).
You consider the current CLI work bikeshedding?
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.
I don't think anyone wants to break anything for the sake of breaking things. I think we want to break things because the project is young and is still making mistakes/learning lessons that are worth correcting early. And while yes, we should consider users, let's also be honest in that our current user base are of the early adopter kind. They can take a bit more churn for the sake of progress. As the project matures, our user base will change and our APIs, UIs, etc will effectively cement and become unchangeable.
Cheers,
-Tristan
Cheers,
Sander
_______________________________________________
BuildStream-list mailing list
BuildStream-list gnome org
https://mail.gnome.org/mailman/listinfo/buildstream-list
