| ================= | |
| buildstream 1.3.1 | |
| ================= | |
| o Failed builds are included in the cache as well. | |
| `bst checkout` will provide anything in `%{install-root}`. | |
| A build including cached fails will cause any dependant elements | |
| to not be scheduled and fail during artifact assembly, | |
| and display the retry prompt during an interactive session. | |
| o Due to enabling the use of relative workspaces, "Legacy" workspaces | |
| may need to be closed and remade before the changes will affect them. | |
| Downgrading after using this feature may result in workspaces | |
| not functioning correctly | |
| o Elements may now specify 'build-depends' and 'runtime-depends' fields | |
| to avoid having to specify the dependency type for every entry in | |
| 'depends'. | |
| o Source plugins may now request access access to previous during track and | |
| fetch by setting `BST_REQUIRES_PREVIOUS_SOURCES_TRACK` and/or | |
| `BST_REQUIRES_PREVIOUS_SOURCES_FETCH` attributes. | |
| o Add new `pip` source plugin for downloading python packages using pip, | |
| based on requirements files from previous sources. | |
| o Generate Docker images from built artifacts using | |
| `contrib/bst-docker-import` script. | |
| ================= | |
| buildstream 1.1.5 | |
| ================= | |
| o Add a `--tar` option to `bst checkout` which allows a tarball to be | |
| created from the artifact contents. | |
| o Fetching and tracking will consult mirrors defined in project config, | |
| and the preferred mirror to fetch from can be defined in the command | |
| line or user config. | |
| o Added new `remote` source plugin for downloading file blobs | |
| o Add support for the new include '(@)' directive in project.conf and .bst files | |
| ================= | |
| 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 | |
| o Switch to Remote Execution CAS-based artifact cache on all platforms. | |
| Artifact servers need to be migrated. | |
| o BuildStream now requires python version >= 3.5 | |
| o BuildStream will now automatically clean up old artifacts when it | |
| runs out of space. The exact behavior is configurable in the user's | |
| buildstream.conf. | |
| ================= | |
| 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 |