rodgert MikeDvorskiy ldionne
- rPSTL358193: [pstl] Setup the _PSTL_VERSION macro like _LIBCPP_VERSION, and add release notes
rGab38599bb124: [pstl] Setup the _PSTL_VERSION macro like _LIBCPP_VERSION, and add release notes
rL358193: [pstl] Setup the _PSTL_VERSION macro like _LIBCPP_VERSION, and add release notes
It's implicit in C++. I mean we can decide to do it like the rest of libc++, but we don't have to. For libc++, the reasoning is that it's needed to test in a freestanding environment.
// The version is XYYZ, where X is major, YY is minor, and Z is patch (i.e. X.YY.Z)
What does a "patch" mean?
May we increment(and rely on) _PSTL_VERSION_PATCH any time when we submitted something fixes or new features?
I think we first need to understand/agree whether we want to have milestones/releases that do not follow the LLVM release cadence while deserving separate versioning. According to the discussion at our last meeting, the answer tends to be "no" - in which case, I think we should keep full correspondence between the upstream PSTL version and the LLVM version.
At Intel, we will need to decide how to combine the upstream versioning with our own one. We have higher release cadence, but also smaller functionality increments. I think that we sometimes will be ahead of the upstream on functionality. I guess we will need a separate version macro; the relations with the upstream version, if any, will need to be clearly defined and documented.