Re: [BuildStream] BuildGrid and BuildStream 1.4 and API concerns

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

Hi Jürg,

Thanks for replying here...

On Mon, 2018-11-26 at 10:23 +0100, Jürg Billeter wrote:
> Hi Tristan,
>
> On Mon, 2018-11-26 at 18:01 +0900, Tristan Van Berkom via BuildStream-list wrote:
> > My question to the developers involved in BuildGrid is:
> >
> >   What is the status of API stability of BuildGrid regarding the
> >   protocols and any parts which BuildStream will directly be
> >   interfacing with ?
> >
> >   Are there any chances that changes in BuildGrid due to it's being
> >   under development, could break BuildStream users ? I.e. can BuildGrid
> >   be safely upgraded without breaking BuildStream and without requiring
> >   lock-step upgrades of both BuildStream and BuildGrid ?
> >
> > I think the answers for this are already "BuildGrid's BuildStream
> > facing APIs are already stable, since they are a standard grpc protocol
> > that is not allowed to break it's API at all" and "No, upgrades to a
> > deployed BuildGrid cannot break interfacing BuildStream clients".
>
> While I believe this to be correct for the basic API, there is no
> standardization yet for the platform attributes for the execution
> environment. This is also currently not implemented on either side. In
> BuildStream this is considered a blocker for 1.4, see #775 and !969.
> For BuildGrid see #104.
>
> While this is not ideal, I expect it to be reasonable for BuildGrid to
> support the platform attributes BuildStream 1.4 will use for the
> foreseeable future, even if the eventual upstream standard may differ
> in some details. I.e., BuildGrid should be able to easily support both,
> in case they will not match.
>
> Assuming the standardization happens between BuildStream 1.4 and 1.6,
> BuildStream 1.6 may no longer work with older BuildGrid, which I think
> is acceptable as BuildGrid hasn't had a stable release yet.

Ok so if I understand correctly, a *newer* version of BuildStream might
require a *newer* version of BuildGrid, but an older version of
BuildStream will not suffer from a new version of BuildGrid.

This sounds perfectly fine, newer versions of BuildStream can always
require new versions of dependencies, I think BuildGrid in this sense
is an optional dependency and it is only important to bail out early
and gracefully if the version of BuildGrid is not new enough for the
new version of BuildStream.

That said, even if BuildGrid does not have a stable release yet, and I
don't think that is an issue, it should at least have a versioning
scheme, or more accurately; BuildStream still needs to be able to find
out if a new enough version of BuildGrid is in place.

Make sense ?

Cheers,
    -Tristan