Preparing Bazel 6.0 release

[Xudong Yang]

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]

FYI +Jason Dobies +Radhika Advani 

--
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]

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.

[1] https://github.com/bazelbuild/continuous-integration/pull/1290#issuecomment-1223567706

[Yun Peng]

Good idea, fixing that in https://github.com/bazelbuild/continuous-integration/pull/1409

[Yun Peng]

Also manually pushed the docker container for 5.3.0

[Tony Aiuto]

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]

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]

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. 

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-dev/02541b67-4e63-488a-a94a-d7c546b9591en%40googlegroups.com.