Good idea. Though, IMO, to maintain multiple versions, we need a bigger
team. To allow coexistence, we also have to figure out a way to deal
with "bazel" and other shared stuff, similar to python/python2/python3
troubles.
Hmmm, good point about dependencies. Our team wiki [1] already identifies the need for multiple bazel-X packages to coexist, and I don't think that part will be overly challenging. However, I hadn't really thought about needing to maintain multiple versions of dependencies. I was assuming that most will be backwards compatible and we can just package the newest version. We may need to implement some patches to make the older version of Bazel work with the newer dependencies. (I think that the focus should always be on cleanly supporting the newest LTS version of Bazel)
Yun: do you foresee any problems with this approach? Do you think any Bazel components (e.g. skylib, stardoc, rules_*, etc.) may break on upgrade in such a way that it would be difficult to patch an older LTS Bazel to work with them?
I'm less worried about third-party libraries since most maintain a level of API stability. It seems more likely to me that the Bazel team might make a bigger API change in components across LTS versions.
-Olek