[libcxx-commits] [PATCH] D150585: [libc++][doc] Updates the tasks to do for a release.

Mark de Wever via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Tue May 23 10:00:50 PDT 2023


Mordante marked 2 inline comments as done.
Mordante added inline comments.


================
Comment at: libcxx/docs/ReleaseProcedure.rst:79-88
+Removal of deprecated features
+==============================
+
+The typical libc++ pattern to remove support for a feature is:
+
+- deprecate a feature in release ``X``,
+- remove that feature in release ``X + 2``.
----------------
ldionne wrote:
> I am not sure that we should keep this section now.
This is indeed an unwanted left over.


================
Comment at: libcxx/docs/ReleaseProcedure.rst:11
+
+Prepare the release
+===================
----------------
philnik wrote:
> Mordante wrote:
> > philnik wrote:
> > > Maybe also check that GCC is on the latest version?
> > I considered that, but left it out on purpose. GCC's release schedule is between releases so there is no nice match with our releases.
> > 
> > Reconsidering it might make sense to do that in the preparation. For Unicode I also don't intend to wait until we prepare the LLVM release, instead I intend to update once I'm aware of the release. That way we at least won't forget about it.
> Yeah, I think it's fine to keep the release preparation phase a bit hand-wavy.
I added a note, but more generic for all our compilers. 


================
Comment at: libcxx/docs/ReleaseProcedure.rst:42
+
+After branching for an LLVM release:
+
----------------
ldionne wrote:
> If we have annotations like `LLVM RELEASE bump`, does it make sense to carry that list around? Duplicating the information IMO is going to create confusion and they'll get out of sync, so I think we should pick one.
> 
> CC @tstellar 
I agree if we have that we can link that, just to make it easier to find for us.

I originally copied this from the contribution page.


================
Comment at: libcxx/docs/ReleaseProcedure.rst:71
+- Search for test that have ``UNSUPPORTED`` or ``XFAIL`` for the no longer supported version
+- Remove the things listed for removal
+
----------------
ldionne wrote:
> philnik wrote:
> > Could we also define a single `TODO LLVM xy` style to make it easier to grep for that?
> I like that! So the documentation could say "Search for `TODO(LLVM-<version>)`" maybe? I don't care about how it's spelled, but we could document it right here and start doing it right away.
I used your suggestion and adjusted the existing TODOs.


================
Comment at: libcxx/docs/ReleaseProcedure.rst:84-107
+LLVM 18
+-------
+
+* The base template for ``std::char_traits`` has been marked as deprecated and
+  will be removed in LLVM 18. If you are using ``std::char_traits`` with types
+  other than ``char``, ``wchar_t``, ``char8_t``, ``char16_t``, ``char32_t`` or
+  a custom character type for which you specialized ``std::char_traits``, your code
----------------
philnik wrote:
> Mordante wrote:
> > philnik wrote:
> > > I don't think we want to list the removals here. We already have the release notes for that.
> > We have, but somehow things from the list are removed by the release managers after branching. Based on your char_traits question and D150580 we need to have a better way to keep track of this. I'm open to other suggestions.
> Wouldn't it be enough to communicate to the release managers that they shouldn't touch the `Upcoming Deprecations and Removals` list? Or maybe move that section into a different file that is included there? (IDK if that's possible with Sphinx) I don't think we had that section when `_LIBCPP_ABI_OLD_LOGNORMAL_DISTRIBUTION` was introduced, and I think the section already massively helps with removing stuff in-time.
For now I just added an item for us to copy it back.


================
Comment at: libcxx/docs/ReleaseProcedure.rst:87-94
+* The base template for ``std::char_traits`` has been marked as deprecated and
+  will be removed in LLVM 18. If you are using ``std::char_traits`` with types
+  other than ``char``, ``wchar_t``, ``char8_t``, ``char16_t``, ``char32_t`` or
+  a custom character type for which you specialized ``std::char_traits``, your code
+  will stop working when we remove the base template. The Standard does not
+  mandate that a base template is provided, and such a base template is bound
+  to be incorrect for some types, which could currently cause unexpected
----------------
ldionne wrote:
> philnik wrote:
> > Mordante wrote:
> > > philnik wrote:
> > > > Where is this coming from?
> > > https://releases.llvm.org/16.0.0/projects/libcxx/docs/ReleaseNotes.html#deprecations-and-removals
> > Could you re-add this to the release notes?
> Instead, I think what we should do here is have version-specific release notes and keep the latest N versions in the repo (probably N = 1). That would actually solve other problems as well, such as merge conflicts during the early branching when we cherry-pick stuff to the release branch.
> 
> Then we could easily obtain this information without having to copy-paste anything, which is going to be error-prone.
For now I moved it to the release notes under a LLVM 18 section. I think it would make sense to do

```
Upcoming Deprecations and Removals
----------------------------------

LLVM 18
~~~~~~~

... list of items

LLVM 19

... list of items

```

I think we can just copy that after the release managers removed it then we don't need to keep N files.



Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150585/new/

https://reviews.llvm.org/D150585



More information about the libcxx-commits mailing list