=================
buildstream 1.1.2
=================

  o New ref-storage option allows one to store source refs, such
    as git shas, in one central project.refs file instead of inline
    with the source declarations.

  o Deprecated `--track-save` optionality in `bst build`, this
    does not make sense to support now that we have project.refs.

  o Added the `sandbox` configuration option which can be used in
    `project.conf` and elements, to control the user ID and group ID
    used in build sandboxes.

  o Added new `deb` source implementation, for staging of downloaded
    deb package files.


=================
buildstream 1.1.1
=================

  o New project configuration controlling how the sandbox behaves
    when `bst shell` is used; allowing projects to provide a more
    functional shell environment.

  o The `bst shell` command now has a `--mount` option allowing
    users to mount files and directories into the sandbox for
    testing purposes.

  o Log lines are now configurable with the new "message-format"
    user configuration, allowing one to express optional fields
    such as microsecond precision and wallclock time.

  o Newly added filter element

  o Git source plugin now allows disabling of submodule checkouts

  o In the same way we allow overriding element configurations
    by their 'kind' in project.conf, we now support the same
    for source plugin configurations.

  o Tar and zip sources now automatically recall an `etag`
    from the http headers, optimizing tracking of tarballs
    significantly (issue #62)


=================
buildstream 1.1.0
=================

  o Multiple artifact caches are now supported in project and
    user configuration with a priority order (issue #85)
  o Add junction support for subprojects
  o Changes towards incremental builds in workspaces
  o `bst shell --build` now creates true build sandbox
  o Many bug fixes


=================
buildstream 1.0.0
=================
First stable release of BuildStream

BuildStream 1.0.0 is all about API stability - for the past months we
have been reviewing our various API surfaces, implementing strategies
for revisioning of our interfaces and cleaning up. Long term stability
is very important for build reproducibility over time, and this release
is the first promise we are making on any API surfaces.

Stable API surfaces include:
  o The command line interface
  o The YAML user configuration file format
  o The YAML project `.bst` file format
  o The core Python module imported by external plugins