Re: Revisions Draft RFC [Re: Proposed public data fields for dpkg build and deploy elements]

[Jonathan Maw <jonathanmaw codethink com>]

On 2017-07-07 10:36, Tristan Van Berkom wrote:
> Forking this thread.
>
> This started as a reply to Jonathan about how to handle format changes
> and migrations for public data, and evolved into a complete draft of
> how we should handle versioning information in general in BuildStream.
[snip]
> BuildStream Format Versions
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
> The format versions are different as they provide a guarantee of what
> features are available to a project.
>
> This is rendered a bit more complex by the fact that third party
> plugins are allowed to exist, this means that the core BuildStream
> format (i.e. conditional statements, dependency declarations, variants,
> etc) needs to have one format revision, and all plugins need to have an
> individual revision as well.
>
> To simplify things; I would propose that we keep a single BuildStream
> format revision and we have all plugins which are hosted in the
> BuildStream source repository use the same revision number.
>
> A project will be able to assert a minimal bound revision for
> BuildStream and for any plugins it uses in the project.conf, if the
> installation of BuildStream has an old revision for the overall format,
> or for any of the loaded plugins; BuildStream will abort and tell the
> user that they need a newer installation for the given project.
>
> Again, from BuildStream 1.0; any additions and enhancements to the
> BuildStream format must remain backwards compatible with older
> versions.
>
> The policy for bumping the BuildStream format revision is, if any
> features have been added to the base format, or to any of the plugins,
> or if a new plugin has been added over the course of a release cycle
> (which should be 6 months following the GNOME release schedule), then
> the format revision must be bumped once immediately; there should be
> only at most 1 revision bump in a given release cycle.
>
>
> Public Data
> ~~~~~~~~~~~
> Public data is a bit tricky, but I think the most straight forward way
> of dealing with this is to say that:
>
>   o Public Data in the "bst" domain is revisioned with the main
>     BuildStream format revision
>
>   o If Public Data is not in the "bst" domain, then it is specific to
>     a given element type which consumes that data, and as such it is
>     revisioned with the format version of the given element plugin.

Hi Tristan,

Do I understand correctly that this means that all plugins in the 
buildstream
repo will use the "bst" domain (hence public data version numbers from 
main
buildstream format), and that domains other than "bst" are for external 
plugins
(and use external plugin format versions)?

Thanks,

Jonathan