Re: [BuildStream] BuildStream Versioning & Releases

[Paul Sherwood <paul sherwood codethink co uk>]

On 2019-01-02 13:11, Sander Striker wrote:
> First of all Happy New Year.

Same to you :-)

<snip>
> My proposal would be to stop doing 1.x releases altogether, and to
> wait with doing a 2.0 release until we are satisfied we can give the
> stability guarantees that are associated with a major release.
> In the meantime we can figure out a way to do 2.0 alpha releases, or
> some other convenience for our early adopters.

That makes sense to me, but what about the folks actually cutting code?

> Can I safely rephrase this as "Increased Adoption"?

Yup :)

> > - bst 'releases' require minimal effort, since they are mostly just
> > a
> > tag and announcement. the real work has been already handled via
> > CI/CD
>
> Ideally.  We may end up with something slightly more than that.  We
> should ensure that mainline development is not impacted by the release
> process though.

Agreed.

> > - bst satisfies all of the criteria for 'trustable software
> > construction' [2]
>
> I think that bst can serve as a tool to accomplish this, but in
> isolation and without context I don't think that is a claim that can
> be made.  That is, whether it can tick the boxes of that definition,
> depends on how the project and bst files are constructed, the
> infrastructure setup, the underlying build systems, etc.

That's true, but I'm only referring to bst in this context.

Put it another way... if bst is used to construct $foo, and something 
surprising/confusing happens (e.g. build fails/succeeds unexpectedly, 
takes longer than it should have done, leads to the wrong output or 
whatever) then bst should never be the source of the confusion/surprise. 
Having certainty about bst should make it easier to figure out the 
actual culprit.

br
Paul