phosek added inline comments.
================
Comment at: clang/lib/Driver/Multilib.cpp:137
+struct MultilibSetSerialization {
+ std::string ClangMinimumVersion;
+ std::vector<MultilibSerialization> Multilibs;
----------------
Can we use a separate versioning scheme rather than tying the version to Clang?
That is start at version 1.0 and bump it every time we make backwards
incompatible change. That's the strategy we've for YAML formats used in other
tools such as
[llvm-ifs](https://llvm.org/docs/CommandGuide/llvm-ifs.html#ifs-formats).
The reason I think that would be preferable is that Clang will be at version
//N.0.0// for ~9 months; we bump the version when we branch of the release,
then spent 6 months developing and then typically another 3 months stabilizing
the release branch. So for example, we bump the version to 16.0.0 in July 2022,
and that version will get released in March 2023. However, during those 9
months, we may want to make more than one breaking change to the format.
This may not be an issue for projects that only follow stable releases, but
there's plenty of major projects that live at HEAD, such as Android, Chromium
or Fuchsia, for which this could cause an issue. Using a dedicated versioning
scheme allows us to decouple the format evolution from Clang releases.
================
Comment at: clang/lib/Driver/Multilib.cpp:137
+struct MultilibSetSerialization {
+ std::string ClangMinimumVersion;
+ std::vector<MultilibSerialization> Multilibs;
----------------
phosek wrote:
> Can we use a separate versioning scheme rather than tying the version to
> Clang? That is start at version 1.0 and bump it every time we make backwards
> incompatible change. That's the strategy we've for YAML formats used in other
> tools such as
> [llvm-ifs](https://llvm.org/docs/CommandGuide/llvm-ifs.html#ifs-formats).
>
> The reason I think that would be preferable is that Clang will be at version
> //N.0.0// for ~9 months; we bump the version when we branch of the release,
> then spent 6 months developing and then typically another 3 months
> stabilizing the release branch. So for example, we bump the version to 16.0.0
> in July 2022, and that version will get released in March 2023. However,
> during those 9 months, we may want to make more than one breaking change to
> the format.
>
> This may not be an issue for projects that only follow stable releases, but
> there's plenty of major projects that live at HEAD, such as Android, Chromium
> or Fuchsia, for which this could cause an issue. Using a dedicated versioning
> scheme allows us to decouple the format evolution from Clang releases.
Use `llvm::VersionTuple` rather than `std::string` which is intended for this
purpose.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D142932/new/
https://reviews.llvm.org/D142932
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
