Page MenuHomePhabricator

[pstl] Setup the _PSTL_VERSION macro like _LIBCPP_VERSION, and add release notes
ClosedPublic

Authored by ldionne on Apr 9 2019, 7:38 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

ldionne created this revision.Apr 9 2019, 7:38 AM
ldionne marked an inline comment as done.Apr 9 2019, 7:39 AM
ldionne added inline comments.
pstl/docs/ReleaseNotes.rst
9 ↗(On Diff #194324)

This doesn't exist yet.

I don't see any "bookmarks" (technical, and others) on scheme versioning on our side.
So, I've no objections against the proposed approach.

ldionne accepted this revision.Apr 11 2019, 10:03 AM

I don't see any "bookmarks" (technical, and others) on scheme versioning on our side.
So, I've no objections against the proposed approach.

Great! Note: when you're OK with a patch, you can use "Accept Revision" in Phabricator so that Phabricator won't complain when I push the patch. I'll accept my own patch for now :)

This revision is now accepted and ready to land.Apr 11 2019, 10:03 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptApr 11 2019, 10:07 AM
MikeDvorskiy added inline comments.Apr 12 2019, 8:41 AM
pstl/trunk/test/pstl/version.pass.cpp
17

lost

return 0;

?

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.

@rodgert @MikeDvorskiy Do you guys want to consistently use return 0; at the end of main? If so, I'll fix this (and any other test that doesn't do it).

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.

@rodgert @MikeDvorskiy Do you guys want to consistently use return 0; at the end of main? If so, I'll fix this (and any other test that doesn't do it).

I do it out of habit (because I'm old and wrote C before C++ was really a thing you could use seriously) but I don't have a strong opinion either way on this.

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.

@rodgert @MikeDvorskiy Do you guys want to consistently use return 0; at the end of main? If so, I'll fix this (and any other test that doesn't do it).

I do it out of habit (because I'm old and wrote C before C++ was really a thing you could use seriously) but I don't have a strong opinion either way on this.

Done in r358302.

// 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?

// 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?

The way I see this used in LLVM is for point releases, e.g. LLVM 7.0.1 (see http://releases.llvm.org). We don't seem to be using the MINOR version anymore though.

In that case, may we "reserve" MINOR version to differ PSTL code version?

In that case, may we "reserve" MINOR version to differ PSTL code version?

I'm not sure I understand what you mean. You mean tracking individual commits using the minor version?

In that case, may we "reserve" MINOR version to differ PSTL code version?

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.