Re: [BuildStream] BuildStream Versioning & Releases

[Sander Striker <s striker striker nl>]

Hi,

First of all Happy New Year.

On Mon, Dec 31, 2018 at 11:20 AM Paul Sherwood <paul sherwood codethink co uk> wrote:

[...]

 

FWIW I previously attempted to get bst releasing and versioning
simplified [1] and didn't get far. Just one of many examples where I and
colleagues failed to achieve common understanding...

Anyway I agree with you that in an alternative universe it would have
been better to avoid claiming 1.x but I'm not sure how we can fix that
now.

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.

 

And I still find that bst is not yet providing the 'stability'
guarantees I care about, so I'm just going to spell out my hopes for
BuildStream 2019:

- multiple downstream projects rely on bst to construct their systems
and environments and help them to manage and track the dependencies of
the software they work on/with

Can I safely rephrase this as "Increased Adoption"?

 

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

 

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

- bst is backwards compatible. new versions of bst can consume old .bst
files, and old cache artefacts 

   (this implies versioning of the cache-key algorithm, and versioning of
the schema for bst files, and maybe versioning of other things too)

+1.

 

- by end of 2019 bst is mostly 'done' - maintenance is a part-time
activity for a few folks who care about it (probably folks who are
mainly using bst to construct software stacks). if bst needs a full-time
army of people to keep it working, we've done it wrong

 

br
Paul

Cheers,

Sander

 

[1]
https://mail.gnome.org/archives/buildstream-list/2018-July/msg00066.html
[2]
https://gitlab.com/trustable/documents/blob/master/markdown/software-construction.md

[...]