Contribute

Bazel Feature Roadmap

This document describes the Bazel team's plans for introducing features that will be incorporated into version 1.0. Note that this roadmap only includes features that the Bazel team itself intends to support. We anticipate that a number of other features will be added by code contributors.

In the following list, each feature is associated with a corresponding milestone. The convention for the priorities are:

  • P0 feature will block the milestone; we will delay the milestone date until the feature is shipped.
  • P1 feature can delay the milestone if the feature can be shipped with a reasonable delay (2 months max).
  • P2 feature will be dropped and rescheduled for later rather than delaying the milestone.

We will update this list when reaching each milestone; some milestones may also be refined if appropriate.

Planned feature list

0.6

2017-07

  • P0. Stable API for Remote execution, excluding platform description
  • P0. List of feature to deprecate until version 1.0 are tracked in a publicly available document
  • P1. Bazel on Windows does not need to install MSYS
  • P1. Migration tool: Maven project to Bazel project

0.7

2017-09

  • P0. Skylark is fully documented; strategy for user-provided Skylark rule documentation
  • P0. Support for Android integration testing (on Linux)
  • P0. Support for Robolectric test for Android (on Linux)
  • P1. The Build Event Protocol is stable
  • P1. Support for coverage can be extended in Skylark and C++
  • P1. Support for testing Skylark rules
  • P1. iOS test runner
  • P1. Better CLI output (--experimental-ui is enabled by default)
  • P2. All external repositories can use the local cache
  • P2. Local caching of build artifacts
  • P2. Bazel can load workspace recursively

0.8

2017-12

  • P0. Support for iOS integration testing
  • P1. Bazel can build Android application on Windows
  • P1. Local caching of external repository is turned on by default and has a deletion strategy
  • P1. Access to native rules functionality from Skylark ("sandwich")
  • P1. Push to Maven public and private artifact repositories
  • P2. Bazel is benchmarked publicly by third parties.

0.9

2018-03

  • P0. Feature parity for Android, Java, C++, Python on Windows
  • P1. Full test suite is open-sourced
  • P2. Minimize need for manual user config to make Bazel fast
  • P2. Repository of BUILD files for third party OSS libraries open to the community

Stable

1.0

2018-06

  • P0. APIs are defined and versioned
  • P1. Deprecated features are removed
  • P1. Support policy is defined regarding LTS release
  • P1. Public review process for design documents

1.1 (LTS)

  • P0. Google uses only public APIs of Bazel
  • P0. Github is the primary code repository
  • P1. Support policy is defined regarding LTS release
  • P1. Bazel respects the standard for Debian packaging
  • P2. Bazel is in the list of Debian package for the next stable

Previously released

Alpha

Released 2015-03-24

Beta

0.1

Released 2015-09-01

0.2

Released 2016-02-18

0.3

Released 2016-06-10

0.4

Released 2016-11-02

0.5

Released 2017-05-26

  • P0. Support for building and testing Java, C++ and Python on Windows
  • P1. Initial API for a Build Event Protocol
  • P1. Support for coverage for Java
  • P1. Bazel installer optionally bundles the JDK
  • P1. New Rules to build applications for Apple platforms
  • P2. Repository rules no longer have invalidation issues

Code location

For the alpha and beta releases, the Bazel team will maintain two code repositories:

  • A Google-internal repository, containing both Bazel code and Google-specific extensions and features
  • An external GitHub repository, containing only the Bazel code.

We anticipate making the external repository primary in the future, that is, code from Google and non-Google contributors will be committed and tested in the external repository first, then imported into the internal repository. For the alpha and beta releases, however, the internal repository will be primary. Changes to Bazel code will be frequently pushed from the internal to the external repository.