Re: [BuildStream] BuildStream Versioning & Releases

[Jürg Billeter <j bitron ch>]

On Thu, 2019-01-03 at 14:09 -0500, Tristan Van Berkom via BuildStream-
list wrote:
> To summarize:
>
>   * We should not make a stable 1.4 release or a 2.0 release
>
>   * We should only make 1.3.x developer snapshots

We should call them 1.90.x, in my opinion, to make it a bit clearer
that they are snapshots leading to 2.0 and don't fully obey the 1.x
stability guarantees.

>   * We at least need to port bugfixes to 1.2.x and make releases of
>     that from time to time, if any bugfixes happen to land on it
>     (I presume this to be very low effort).
>
>   * At some undecided day in the future when we think we're really
>     ready to be stable, we can make a 2.0 release then.
>
> In general this works for me.
>
> If we went down this road, I would still very much want master to
> remain backwards compatible with the 1.2 YAML format... my concern is
> that we should be able to test BuildStream master against existing
> projects which choose to use 1.2, and not be restricted to only being
> usable with projects who have migrated to something new.
>
> If this is impossible for some reason, we should keep a migration guide
> up to date and make efforts to make the transition painless.

This works for me as well and should make my/our life easier in a few
areas. E.g., we can mandate plugins to support the virtual directory
API (all plugins will then work with remote execution / BuildBox). And
the transition to source cache should also be easier. We should also be
able to simplify symlink handling without having to worry too much
about theoretical corner cases with regards to backward compatibility.

I agree that we should still make the transition as painless as
possible, however, e.g., this allows us to add 1.2 compatibility code
to (external) plugins instead of a more painful dual API approach in
BuildStream core.

Cheers,
Jürg