| ================= |
| buildstream 1.1.4 |
| ================= |
| |
| o `bst workspace` commands and `bst track` will substitute their |
| source elements when performing those operations, e.g. performing |
| `bst track` on a filter element will track the sources on the |
| element that it depends on (if it has sources). |
| |
| o Added new simple `make` element |
| |
| |
| ================= |
| buildstream 1.1.3 |
| ================= |
| |
| o Added new `bst init` command to initialize a new project. |
| |
| o Cross junction tracking is now disabled by default for projects |
| which can support this by using project.refs ref-storage |
| |
| New options have been added to explicitly enable cross-junction |
| tracking. |
| |
| o Failed jobs are now summarised at the end of a build. |
| |
| Use `--verbose` and `--no-verbose` to adjust the amount of detail given. |
| |
| o BuildElements' `configure-commands` are only run once for |
| workspaces now, which allows for incremental builds. |
| |
| Appropriate API for plugins is also exposed through |
| `Element.prepare`. |
| |
| o The `cmake` plugin now supports building with ninja with the |
| newly added `generator` configuration option. |
| |
| o `bst workspace close` and `bst workspace reset` now support multiple |
| elements. All elements can be specified using `--all`. |
| |
| o The elements whose cache keys had to be determined during the build |
| are summarised at the end of the build. |
| |
| o Fixed versioning introspection to be dynamic, many users use |
| a developer install mode so they can update with git, now the |
| version information is always up to date in logs. |
| |
| This causes a minor API break: The --version output now only |
| outputs the version. |
| |
| |
| ================= |
| 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 |
