Re: [BuildStream] BuildStream Versioning & Releases, WAS: Re: bst CLI design and consistency (UI)

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

Hi Sander,

Hope everyone had a happy holiday, sorry for being late to the party :)

On Thu, 2018-12-20 at 10:46 +0000, Sander Striker wrote:
> Hi,
>
> Given most of what we're talking about has more to do with
> versioning, specific to BuildStream, I've changed the subject to
> reflect that.

> Tristan, I know you care a lot about the project, please take this as
> a constructive perspective on how I see where we are.

[...]
> > Making statements that we are "pre-1.x" only goes towards sewing
> > distrust in our existing user base, who have real needs, and to whom we
> > need to demonstrate our reliability.
>
> Quite the opposite.  Making guarantees that we cannot and should not
> make is what creates distrust down the line.  Much like what is
> happening with 1.4 right now in which we chose to break things.  And
> that opened the door for taking a real critical look, and breaking
> more things to improve the experience.

Right, I understand we don't see this the same way... to illustrate
I'll quote you from below (because it's very relevant):

   "Which is why mass adoption cements interfaces, and makes them
    unchangeable forever."

I think it's fair to say that we mostly disagree about whether the
chicken or the egg comes first (I think that instead, maintaining
stable interfaces is one of the necessary precursors to adoption).

My perspective has been that offering stability requires a certain
discipline for a project which costs a learning curve of its own, and
that introducing that discipline earlier was better for the project's
health.

[...]
> > Stability of cache keys was *never* a guarantee, I'll re-post the link
> > to the original set of API stability guarantees:
> >
> >     https://mail.gnome.org/archives/buildstream-list/2018-January/msg00006.html
>
> Was that the correct link?  I'm not sure what I am supposed to take away from that.

Sorry, that was the wrong release mail from the same month:

    https://mail.gnome.org/archives/buildstream-list/2018-January/msg00000.html

> If you did post a link to a message, I question what user is going
> read that do you think?  If as a user I find a 1.x release, that
> comes with certain expectations.  And if it doesn't, then I go back
> and read about what this specific project meant with their version 
> numbers, and likely be disappointed.

I agree this is a fair sentiment.

I have seen this as rather similar to whether we exported a python
library API or not (i.e. this is about "how much" we declare "public"
and as such has to be stable) - but there is no way for a user to guess
that a cache key is going to be stable or not.

[...]
> If stability has exceptions, then calling it stable is a stretch at
> best.  It's then better to label as 0.x and be specific about what is
> stable, rather than the other way around.  Unfortunately we already
> burned the 1.x major number putting us on the path of burning more
> major version numbers.  Or declaring bankruptcy on 1.x.
>
> There is a good reason that bazel is still at 0.x, being 4 years in. 
> It took subversion 2.5 years to go from self-hosting to a 1.0 release
> (http://subversion.apache.org/docs/release-notes/release-history.html
> ).  Apache portable runtime took 2 years and change IIRC to go from
> 0.9.x to 1.0.

[...]
> I think that is a mistake and will put the 2.x series on the same
> path as the 1.x series.  This proposed 2.0 would still suffer from
> not being performant enough and from not having e.g. cache key
> stability.  Which, for what it's worth I'm only using as examples.

I think this is leading into your proposal so I'll continue this in the
other thread...

Cheers,
    -Tristan