F40 Change Proposal: LLVM 18 (System-Wide)

[Aoife Moloney]

Wiki -> https://fedoraproject.org/wiki/Changes/LLVM-18

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Update all llvm sub-projects in Fedora Linux to version 18.


== Owner ==
* Name: [[User:tstellar| Tom Stellard]]
* Email: <tstellar(a)redhat.com&gt;


== Detailed Description ==
All llvm sub-projects in Fedora will be updated to version 18, and
there will be a soname version change for the llvm libraries.
Compatibility packages clang17, llvm17, and lld17 will be added to
ensure that packages that currently depend on clang and llvm version
17 libraries will continue to work.  We may add other compatibility
packages too if they're determined to be necessary to maintain
functionality in other RPMS that use llvm/clang.  We also plan to
retire these older compatibility packages (that we own):

* llvm14
* llvm15
* llvm16
* clang14
* clang15
* clang16
* lld14
* lld15
* lld16

We will also be asking the maintainers of the following packages to
retire them if possible:

* llvm7.0
* llvm8.0
* llvm11
* llvm12
* llvm13

Other notable changes:

* clang will emit DWARF-5 by default instead of DWARF-4.  This matches
the upstream default.  We have been using DWARF-4 as the default for
the last few releases due to:
https://bugzilla.redhat.com/show_bug.cgi?id=2064052
* The compatibility packages will now include the same content as the
main package.  In previous releases, the compatibility packages
contained only libraries and headers, and the binaries and other
content was stripped out.  These packages will be supported for use as
dependencies for other RPM packages, but not for general purpose usage
by end users.  Fedora users should use Clang/LLVM 18.
* The compatibility packages added for Fedora 40 will be retired prior
to the Fedora 41 branch.
* We will be enabling Fat LTO in redhat-rpm-config if this feature is
complete in time for the upstream LLVM 18 release.  Fat LTO is a
feature that allows the compiler to produce libraries that contain LTO
bitcode along side the traditional ELF binary code so that the
libraries can be linked in both LTO mode and non-LTO mode.  gcc also
supports this feature and has it enabled in Fedora.  In Fedora 39 and
older, with LTO enabled, clang produces binaries with only LTO
bitcode, so we need to run a post-processing script
(brp-llvm-compile-to-elf) on the libraries to convert them to ELF code
so they can be used by other packages.  Enabling Fat LTO will allow us
to remove this script and simplify the build process.

===LLVM Build Schedule===

====Important Dates====

* Jan  26: Upstream: 18.0.0-rc1 Release
* Feb   6: Fedora: f40 branch created
* Feb   6: Upstream: 18.0.0-rc2 Release
* Feb  20: Fedora: f40 Beta Freeze
* Feb  20: Upstream: 18.0.0-rc3 Release
* Mar   5: Upstream: 18.0.0 Release
* Apr   2: Fedora: f40 Final Freeze

====Plan====
# Build nightly trunk (LLVM 18) snapshots in
[https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots...
copr].
# Build LLVM 18.0.0-rc1 in COPR.
# Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji.
# Build LLVM 18.0.0-rc1 into a f39 side-tag in Koji.
# Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji.
# Build LLVM 18.0.0-rc2 into a f39 side-tag in Koji.
# Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji
# Build LLVM 18.0.0-rc3 into a f39 side-tag in Koji
# Push F39 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not
ready) as a Beta Freeze exception.
# Continue building new release candidates and pushing them to stable
until the Final Freeze.

We are not planning to push 18.0.0-rc1 into rawhide because the
library ABI is not stabilized at that point. Typically, the ABI
stabilizes after -rc3, but there are no guarantees from upstream about
this.  Given the history of minimal ABI changes after -rc3, we feel
like it's safe to push -rc3 into rawhide.  The worst case scenario
would be an ABI change -rc4 or the final release that we force us to
patch LLVM to maintain compatibility with the -rc3 ABI.  This scenario
would not require rebuilding LLVM library users in Fedora, so this
would not require much extra work from our team.

Updates after 18.0.0-rc3 will generally be very small and can be done
after the Final Freeze is over.  If we are late packaging release
candidates after -rc3 or the final release, we will not ask for a
Final Freeze exception, unless they contain a fix for a critical
release blocking bug.

== Feedback ==


== Benefit to Fedora ==
New features and bug fixes provided by the latest version of LLVM.

== Scope ==
* Proposal owners:

** Review existing llvm and clang compatibility packages and orphan
any packages that are no longer used.
** Build and test early release candidates of LLVM 18 in COPR.

* Other developers:
** Fix build issues found with LLVM-18 or switch their package to use
the llvm17 compat libs.  The LLVM team will not block Bodhi updates on
dependent packages that fail to build or run with LLVM-18.  There
should be around 6-8 weeks between when -rc1 lands in the koji
side-tag and the Final Freeze for package maintainers to fix issues
uncovered with the LLVM-18 update.

* Release engineering: [https://pagure.io/releng/issue/11845 #11845]

* Policies and guidelines: N/A (not needed for this Change)

* Trademark approval: N/A (not needed for this Change)


* Alignment with Community Initiatives:


== Upgrade/compatibility impact ==

This change should not impact upgrades.

== How To Test ==

The CI tests for the llvm sub-packages in Fedora will be used to catch
regressions that might be potentially introduced by the update to LLVM
18.

== User Experience ==


== Dependencies ==

Packages that depend on one of the llvm packages will need to be
updated to work with LLVM18 or will need to switch to using one of the
llvm17 compat packages.

== Contingency Plan ==
* Contingency mechanism: (What to do?  Who will do it?) N/A (not a
System Wide Change)
If there are major problems with LLVM 18, the compatibility package
provide a way for other packages to continue using LLVM 17.

* Contingency deadline: Final Freeze

== Documentation ==

LLVM sub-projects in Fedora have been updated to version 18:

*llvm
*clang
*lld
*lldb
*compiler-rt
*libomp
*llvm-test-suite
*libcxx
*python-lit
*flang
*mlir
*polly
*libclc
*llvm-bolt

== Release Notes ==


-- 
Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Stephen Gallagher]

On Fri, Dec 22, 2023 at 8:05 PM Aoife Moloney <amoloney(a)redhat.com&gt; wrote:
>  Wiki -> https://fedoraproject.org/wiki/Changes/LLVM-18
>
>  This document represents a proposed Change. As part of the Changes
>  process, proposals are publicly announced in order to receive
>  community feedback. This proposal will only be implemented if approved
>  by the Fedora Engineering Steering Committee.
>
>  == Summary ==
>  Update all llvm sub-projects in Fedora Linux to version 18.
>
>
>  == Owner ==
>  * Name: [[User:tstellar| Tom Stellard]]
>  * Email: <tstellar(a)redhat.com&gt;
>
>
>  == Detailed Description ==
>  All llvm sub-projects in Fedora will be updated to version 18, and
>  there will be a soname version change for the llvm libraries.
>  Compatibility packages clang17, llvm17, and lld17 will be added to
>  ensure that packages that currently depend on clang and llvm version
>  17 libraries will continue to work.  We may add other compatibility
>  packages too if they're determined to be necessary to maintain
>  functionality in other RPMS that use llvm/clang.  We also plan to
>  retire these older compatibility packages (that we own):
>
>  * llvm14
>  * llvm15
>  * llvm16
>  * clang14
>  * clang15
>  * clang16
>  * lld14
>  * lld15
>  * lld16
>
>  We will also be asking the maintainers of the following packages to
>  retire them if possible:
>
>  * llvm7.0
>  * llvm8.0
>  * llvm11
>  * llvm12
>  * llvm13
>
>  Other notable changes:
>
>  * clang will emit DWARF-5 by default instead of DWARF-4.  This matches
>  the upstream default.  We have been using DWARF-4 as the default for
>  the last few releases due to:
>  https://bugzilla.redhat.com/show_bug.cgi?id=2064052
>  * The compatibility packages will now include the same content as the
>  main package.  In previous releases, the compatibility packages
>  contained only libraries and headers, and the binaries and other
>  content was stripped out.  These packages will be supported for use as
>  dependencies for other RPM packages, but not for general purpose usage
>  by end users.  Fedora users should use Clang/LLVM 18.
>  * The compatibility packages added for Fedora 40 will be retired prior
>  to the Fedora 41 branch.
>  * We will be enabling Fat LTO in redhat-rpm-config if this feature is
>  complete in time for the upstream LLVM 18 release.  Fat LTO is a
>  feature that allows the compiler to produce libraries that contain LTO
>  bitcode along side the traditional ELF binary code so that the
>  libraries can be linked in both LTO mode and non-LTO mode.  gcc also
>  supports this feature and has it enabled in Fedora.  In Fedora 39 and
>  older, with LTO enabled, clang produces binaries with only LTO
>  bitcode, so we need to run a post-processing script
>  (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code
>  so they can be used by other packages.  Enabling Fat LTO will allow us
>  to remove this script and simplify the build process.
>
>  ===LLVM Build Schedule===
>
>  ====Important Dates====
>
>  * Jan  26: Upstream: 18.0.0-rc1 Release
>  * Feb   6: Fedora: f40 branch created
>  * Feb   6: Upstream: 18.0.0-rc2 Release
>  * Feb  20: Fedora: f40 Beta Freeze
>  * Feb  20: Upstream: 18.0.0-rc3 Release
>  * Mar   5: Upstream: 18.0.0 Release
>  * Apr   2: Fedora: f40 Final Freeze
>
>  ====Plan====
>  # Build nightly trunk (LLVM 18) snapshots in
>  [https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots...
>  copr].
>  # Build LLVM 18.0.0-rc1 in COPR.
>  # Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji.
>  # Build LLVM 18.0.0-rc1 into a f39 side-tag in Koji.
>  # Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji.
>  # Build LLVM 18.0.0-rc2 into a f39 side-tag in Koji.
>  # Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji
>  # Build LLVM 18.0.0-rc3 into a f39 side-tag in Koji
>  # Push F39 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not
>  ready) as a Beta Freeze exception.
>  # Continue building new release candidates and pushing them to stable
>  until the Final Freeze.
>
>  We are not planning to push 18.0.0-rc1 into rawhide because the
>  library ABI is not stabilized at that point. Typically, the ABI
>  stabilizes after -rc3, but there are no guarantees from upstream about
>  this.  Given the history of minimal ABI changes after -rc3, we feel
>  like it's safe to push -rc3 into rawhide.  The worst case scenario
>  would be an ABI change -rc4 or the final release that we force us to
>  patch LLVM to maintain compatibility with the -rc3 ABI.  This scenario
>  would not require rebuilding LLVM library users in Fedora, so this
>  would not require much extra work from our team.
>
>  Updates after 18.0.0-rc3 will generally be very small and can be done
>  after the Final Freeze is over.  If we are late packaging release
>  candidates after -rc3 or the final release, we will not ask for a
>  Final Freeze exception, unless they contain a fix for a critical
>  release blocking bug.
>
>  == Feedback ==
>  
This came in while I was on PTO, so my apologies for the late reply on it.

My concern here is with the timing and its inclusion into Fedora ELN
(and, by extension, CentOS Stream 10). The public plan for CS 10 is
that it will break inheritance from Fedora Rawhide/ELN at the Fedora
40 branch point (Feb. 6th). By the schedule you've listed here, that
means this Change will land in Fedora after we branch, which will
likely mean that this (not-inconsiderable) effort will need to be
replicated in the CentOS Stream 10 environment, rather than being
simply inherited through Fedora ELN. Once the proposed Bodhi update
arrives during Beta Freeze, it will be picked up by Fedora ELN... but
at that point ELN will be tracking RHEL/CentOS Stream 11.

I'm not sure this is an avoidable situation, given the upstream
release schedule, but I want to make sure we call it out so you can
prepare for it.

[Josh Stone]

On 1/5/24 5:18 AM, Stephen Gallagher wrote:
>  On Fri, Dec 22, 2023 at 8:05 PM Aoife Moloney
> <amoloney(a)redhat.com&gt; wrote:
> >
> > Wiki -> https://fedoraproject.org/wiki/Changes/LLVM-18
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > Update all llvm sub-projects in Fedora Linux to version 18.
> >
> >
> > == Owner ==
> > * Name: [[User:tstellar| Tom Stellard]]
> > * Email: <tstellar(a)redhat.com&gt;
> >
> >
> > == Detailed Description ==
> > All llvm sub-projects in Fedora will be updated to version 18, and
> > there will be a soname version change for the llvm libraries.
> > Compatibility packages clang17, llvm17, and lld17 will be added to
> > ensure that packages that currently depend on clang and llvm version
> > 17 libraries will continue to work.  We may add other compatibility
> > packages too if they're determined to be necessary to maintain
> > functionality in other RPMS that use llvm/clang.  We also plan to
> > retire these older compatibility packages (that we own):
> >
> > * llvm14
> > * llvm15
> > * llvm16
> > * clang14
> > * clang15
> > * clang16
> > * lld14
> > * lld15
> > * lld16
> >
> > We will also be asking the maintainers of the following packages to
> > retire them if possible:
> >
> > * llvm7.0
> > * llvm8.0
> > * llvm11
> > * llvm12
> > * llvm13
> >
> > Other notable changes:
> >
> > * clang will emit DWARF-5 by default instead of DWARF-4.  This matches
> > the upstream default.  We have been using DWARF-4 as the default for
> > the last few releases due to:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2064052
> > * The compatibility packages will now include the same content as the
> > main package.  In previous releases, the compatibility packages
> > contained only libraries and headers, and the binaries and other
> > content was stripped out.  These packages will be supported for use as
> > dependencies for other RPM packages, but not for general purpose usage
> > by end users.  Fedora users should use Clang/LLVM 18.
> > * The compatibility packages added for Fedora 40 will be retired prior
> > to the Fedora 41 branch.
> > * We will be enabling Fat LTO in redhat-rpm-config if this feature is
> > complete in time for the upstream LLVM 18 release.  Fat LTO is a
> > feature that allows the compiler to produce libraries that contain LTO
> > bitcode along side the traditional ELF binary code so that the
> > libraries can be linked in both LTO mode and non-LTO mode.  gcc also
> > supports this feature and has it enabled in Fedora.  In Fedora 39 and
> > older, with LTO enabled, clang produces binaries with only LTO
> > bitcode, so we need to run a post-processing script
> > (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code
> > so they can be used by other packages.  Enabling Fat LTO will allow us
> > to remove this script and simplify the build process.
> >
> > ===LLVM Build Schedule===
> >
> > ====Important Dates====
> >
> > * Jan  26: Upstream: 18.0.0-rc1 Release
> > * Feb   6: Fedora: f40 branch created
> > * Feb   6: Upstream: 18.0.0-rc2 Release
> > * Feb  20: Fedora: f40 Beta Freeze
> > * Feb  20: Upstream: 18.0.0-rc3 Release
> > * Mar   5: Upstream: 18.0.0 Release
> > * Apr   2: Fedora: f40 Final Freeze
> >
> > ====Plan====
> > # Build nightly trunk (LLVM 18) snapshots in
> > [https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots...
> > copr].
> > # Build LLVM 18.0.0-rc1 in COPR.
> > # Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji.
> > # Build LLVM 18.0.0-rc1 into a f39 side-tag in Koji.
> > # Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji.
> > # Build LLVM 18.0.0-rc2 into a f39 side-tag in Koji.
> > # Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji
> > # Build LLVM 18.0.0-rc3 into a f39 side-tag in Koji
> > # Push F39 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not
> > ready) as a Beta Freeze exception.
> > # Continue building new release candidates and pushing them to stable
> > until the Final Freeze.
> >
> > We are not planning to push 18.0.0-rc1 into rawhide because the
> > library ABI is not stabilized at that point. Typically, the ABI
> > stabilizes after -rc3, but there are no guarantees from upstream about
> > this.  Given the history of minimal ABI changes after -rc3, we feel
> > like it's safe to push -rc3 into rawhide.  The worst case scenario
> > would be an ABI change -rc4 or the final release that we force us to
> > patch LLVM to maintain compatibility with the -rc3 ABI.  This scenario
> > would not require rebuilding LLVM library users in Fedora, so this
> > would not require much extra work from our team.
> >
> > Updates after 18.0.0-rc3 will generally be very small and can be done
> > after the Final Freeze is over.  If we are late packaging release
> > candidates after -rc3 or the final release, we will not ask for a
> > Final Freeze exception, unless they contain a fix for a critical
> > release blocking bug.
> >
> > == Feedback ==
> >
>  
>  This came in while I was on PTO, so my apologies for the late reply on it.
>  
>  My concern here is with the timing and its inclusion into Fedora ELN
>  (and, by extension, CentOS Stream 10). The public plan for CS 10 is
>  that it will break inheritance from Fedora Rawhide/ELN at the Fedora
>  40 branch point (Feb. 6th). By the schedule you've listed here, that
>  means this Change will land in Fedora after we branch, which will
>  likely mean that this (not-inconsiderable) effort will need to be
>  replicated in the CentOS Stream 10 environment, rather than being
>  simply inherited through Fedora ELN. Once the proposed Bodhi update
>  arrives during Beta Freeze, it will be picked up by Fedora ELN... but
>  at that point ELN will be tracking RHEL/CentOS Stream 11. 
Without committing anything on their behalf -- I expect this will not be
the final LLVM for CS 10 anyway. We've been rebasing LLVM every 6 months
in CS and RHEL (like Rust and Go), and looking back you can see that CS9
also had different LLVM versions between beta and GA.

>  I'm not sure this is an avoidable situation, given the upstream
>  release schedule, but I want to make sure we call it out so you can
>  prepare for it.
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Tom Stellard]

On 1/5/24 05:18, Stephen Gallagher wrote:
>  On Fri, Dec 22, 2023 at 8:05 PM Aoife Moloney
> <amoloney(a)redhat.com&gt; wrote:
> >
> > Wiki -> https://fedoraproject.org/wiki/Changes/LLVM-18
> >
> > This document represents a proposed Change. As part of the Changes
> > process, proposals are publicly announced in order to receive
> > community feedback. This proposal will only be implemented if approved
> > by the Fedora Engineering Steering Committee.
> >
> > == Summary ==
> > Update all llvm sub-projects in Fedora Linux to version 18.
> >
> >
> > == Owner ==
> > * Name: [[User:tstellar| Tom Stellard]]
> > * Email: <tstellar(a)redhat.com&gt;
> >
> >
> > == Detailed Description ==
> > All llvm sub-projects in Fedora will be updated to version 18, and
> > there will be a soname version change for the llvm libraries.
> > Compatibility packages clang17, llvm17, and lld17 will be added to
> > ensure that packages that currently depend on clang and llvm version
> > 17 libraries will continue to work.  We may add other compatibility
> > packages too if they're determined to be necessary to maintain
> > functionality in other RPMS that use llvm/clang.  We also plan to
> > retire these older compatibility packages (that we own):
> >
> > * llvm14
> > * llvm15
> > * llvm16
> > * clang14
> > * clang15
> > * clang16
> > * lld14
> > * lld15
> > * lld16
> >
> > We will also be asking the maintainers of the following packages to
> > retire them if possible:
> >
> > * llvm7.0
> > * llvm8.0
> > * llvm11
> > * llvm12
> > * llvm13
> >
> > Other notable changes:
> >
> > * clang will emit DWARF-5 by default instead of DWARF-4.  This matches
> > the upstream default.  We have been using DWARF-4 as the default for
> > the last few releases due to:
> > https://bugzilla.redhat.com/show_bug.cgi?id=2064052
> > * The compatibility packages will now include the same content as the
> > main package.  In previous releases, the compatibility packages
> > contained only libraries and headers, and the binaries and other
> > content was stripped out.  These packages will be supported for use as
> > dependencies for other RPM packages, but not for general purpose usage
> > by end users.  Fedora users should use Clang/LLVM 18.
> > * The compatibility packages added for Fedora 40 will be retired prior
> > to the Fedora 41 branch.
> > * We will be enabling Fat LTO in redhat-rpm-config if this feature is
> > complete in time for the upstream LLVM 18 release.  Fat LTO is a
> > feature that allows the compiler to produce libraries that contain LTO
> > bitcode along side the traditional ELF binary code so that the
> > libraries can be linked in both LTO mode and non-LTO mode.  gcc also
> > supports this feature and has it enabled in Fedora.  In Fedora 39 and
> > older, with LTO enabled, clang produces binaries with only LTO
> > bitcode, so we need to run a post-processing script
> > (brp-llvm-compile-to-elf) on the libraries to convert them to ELF code
> > so they can be used by other packages.  Enabling Fat LTO will allow us
> > to remove this script and simplify the build process.
> >
> > ===LLVM Build Schedule===
> >
> > ====Important Dates====
> >
> > * Jan  26: Upstream: 18.0.0-rc1 Release
> > * Feb   6: Fedora: f40 branch created
> > * Feb   6: Upstream: 18.0.0-rc2 Release
> > * Feb  20: Fedora: f40 Beta Freeze
> > * Feb  20: Upstream: 18.0.0-rc3 Release
> > * Mar   5: Upstream: 18.0.0 Release
> > * Apr   2: Fedora: f40 Final Freeze
> >
> > ====Plan====
> > # Build nightly trunk (LLVM 18) snapshots in
> > [https://copr.fedorainfracloud.org/coprs/g/fedora-llvm-team/llvm-snapshots...
> > copr].
> > # Build LLVM 18.0.0-rc1 in COPR.
> > # Build LLVM 18.0.0-rc1 into a rawhide side-tag in Koji.
> > # Build LLVM 18.0.0-rc1 into a f39 side-tag in Koji.
> > # Build LLVM 18.0.0-rc2 into a rawhide side-tag in Koji.
> > # Build LLVM 18.0.0-rc2 into a f39 side-tag in Koji.
> > # Build LLVM 18.0.0-rc3 into a rawhide side-tag in Koji
> > # Build LLVM 18.0.0-rc3 into a f39 side-tag in Koji
> > # Push F39 Bodhi Update with 18.0.0-rc3 (or 18.0.0-rc2 if -rc3 is not
> > ready) as a Beta Freeze exception.
> > # Continue building new release candidates and pushing them to stable
> > until the Final Freeze.
> >
> > We are not planning to push 18.0.0-rc1 into rawhide because the
> > library ABI is not stabilized at that point. Typically, the ABI
> > stabilizes after -rc3, but there are no guarantees from upstream about
> > this.  Given the history of minimal ABI changes after -rc3, we feel
> > like it's safe to push -rc3 into rawhide.  The worst case scenario
> > would be an ABI change -rc4 or the final release that we force us to
> > patch LLVM to maintain compatibility with the -rc3 ABI.  This scenario
> > would not require rebuilding LLVM library users in Fedora, so this
> > would not require much extra work from our team.
> >
> > Updates after 18.0.0-rc3 will generally be very small and can be done
> > after the Final Freeze is over.  If we are late packaging release
> > candidates after -rc3 or the final release, we will not ask for a
> > Final Freeze exception, unless they contain a fix for a critical
> > release blocking bug.
> >
> > == Feedback ==
> >
>  
>  This came in while I was on PTO, so my apologies for the late reply on it.
>  
>  My concern here is with the timing and its inclusion into Fedora ELN
>  (and, by extension, CentOS Stream 10). The public plan for CS 10 is
>  that it will break inheritance from Fedora Rawhide/ELN at the Fedora
>  40 branch point (Feb. 6th). By the schedule you've listed here, that
>  means this Change will land in Fedora after we branch, which will
>  likely mean that this (not-inconsiderable) effort will need to be
>  replicated in the CentOS Stream 10 environment, rather than being
>  simply inherited through Fedora ELN. Once the proposed Bodhi update
>  arrives during Beta Freeze, it will be picked up by Fedora ELN... but
>  at that point ELN will be tracking RHEL/CentOS Stream 11.
>  
>  I'm not sure this is an avoidable situation, given the upstream
>  release schedule, but I want to make sure we call it out so you can
>  prepare for it.
>   
Thanks. There is nothing we can really do about this, so we already
have plans to do a separate version update in CentOS Stream 10.

-Tom