Preparing Bazel 6.0 release

57 views
Skip to first unread message

Xudong Yang

unread,
Aug 24, 2022, 6:15:47 AMAug 24
to bazel-dev, bazel-discuss
Hi all,

We're planning to cut the baseline for Bazel 6.0, the next LTS (long-term support) release, around 2022-09-12. Please submit any changes you'd like to get into Bazel 6.0 before then; if your outstanding PR still needs approval from a Bazel team member, please add a comment on the release tracking issue. After the baseline is cut, cherry pick PRs will still be accepted, but only for crucial bug fixes.

Thanks,
Xudong

Yun Peng

unread,
Aug 24, 2022, 7:25:42 AMAug 24
to Xudong Yang, Jason Dobies, Radhika Advani, bazel-dev, bazel-discuss
--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CADMn-5Z_D1%3DB%3DdehVm90vkACYHhiUVA9-hi%3DiZAjnWnRkbxXyw%40mail.gmail.com.

Jason Dobies

unread,
Aug 24, 2022, 9:27:41 AMAug 24
to Yun Peng, Xudong Yang, Radhika Advani, bazel-dev, bazel-discuss
Speaking of the next release, can we add into the release process to push updated container images? There's a request for the same for 5.3 [1] and it'd be good for us to simply consider that part of the regular release process.

Yun Peng

unread,
Aug 24, 2022, 9:45:08 AMAug 24
to Jason Dobies, Xudong Yang, Radhika Advani, bazel-dev, bazel-discuss

Yun Peng

unread,
Aug 24, 2022, 9:45:23 AMAug 24
to Jason Dobies, Xudong Yang, Radhika Advani, bazel-dev, bazel-discuss
Also manually pushed the docker container for 5.3.0

Tony Aiuto

unread,
Aug 24, 2022, 3:52:53 PMAug 24
to Yun Peng, Jason Dobies, Radhika Advani, Sven Tiffe, Xudong Yang, bazel-dev, bazel-discuss, bazel-...@googlegroups.com
I have a radical proposal.

Some subset of the Bazel team (Eng + PM + DevRel) should, together, look at every outstanding PR, especially lingering ones like Xavier's glob ones, and decide if we should hold the 6.0 release for it. 

We should also take it a step further and close the ones which we would have rejected in the first place, but no one wanted to be the baddie. 




You received this message because you are subscribed to the Google Groups "bazel-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/CAOZBPs73wq5VFdggy-g6SvztS-cLDyTggw6vgX%2BBM3_hsF39zw%40mail.gmail.com.

Xavier Bonaventura

unread,
Sep 13, 2022, 3:40:01 AMSep 13
to bazel-dev
A general thing that would be good to have for Bazel 6 is a bit of cleanup of no-op options.
There are several no-ops that were no-op in Bazel 5 but they  have not been removed.
I created a PR removing some of them in case there is interest https://github.com/bazelbuild/bazel/pull/16259
Most probably I forgot some, the best would be to have an automated way to detect the ones that were no-op in Bazel 5 and they are still not removed.
Some of them are even documented, removing them makes documentation a bit more compact.

Tony Aiuto

unread,
Sep 13, 2022, 11:54:49 AMSep 13
to Xavier Bonaventura, bazel-dev
Once they go into the GraveyardOptions, we leave them there for at least 6 months.
That is for a rollback policy, where we want to be able to roll the build environment (including .bazelrc) back in time but use a new version of bazel. 

What we should do put a delete date on anything we move to the graveyard. That would save time in hunting them down.

The fact that some are documented is a mistake. That should be fixed.
We should have caught that in code review. 

Reply all
Reply to author
Forward
0 new messages