Hi Liming,

Thank you, that is appreciated. Going forward I'll let you know if I
trip over any not already documented.

-dann

On Tue, Dec 6, 2022 at 5:59 PM gaoliming via groups.io
<gaoliming@...> wrote:

Dann:
I base on new features to collect the incompatible changes, and add them into the updated notes.

If you find any missing, please send the mail to me.

Thanks
Liming

-----邮件原件-----
发件人: Kinney, Michael D <michael.d.kinney@...>
发送时间: 2022年12月6日 9:22
收件人: devel@edk2.groups.io; dann.frazier@...; Gao, Liming
<gaoliming@...>
主题: RE: [edk2-devel] feature flag change notifications

Hi Dann,

These are reasonable requests.

Adding Liming Gao who is currently responsible for the edk2 releases.

Let's start with release notes and see if some of these can be added
to the release documentation and add to the edk2 release process
to clearly note these type of changes in future release notes.

As far as #error and #warn. Those are possible, but we would need
to do some analysis for the types of changes that would require
that behavior. Your examples are useful as a starting point.

Once concern is how many of those #error/#warn conditions will
build up over time and then a process to remove them after an
expiration period.

Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of dann

frazier

Sent: Monday, December 5, 2022 4:10 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] feature flag change notifications

Hi,
I maintain the edk2 packages in the Debian and Ubuntu
distributions. A few times over the years I've had users report
regressions that turned out to be due to upstream build flag
changes. I wonder if it would be possible for upstream to communicate
such changes - either via release notes or, where possible, as
build-time checks - to us downstream projects. Here are the examples I
recall:

commit 4de8d61bcec02a13ceed84f92b0cf3ea58adf9c5
Author: Gerd Hoffmann <kraxel@...>
Date: Wed Dec 15 12:39:20 2021 +0100

OvmfPkg: rework TPM configuration

For this I needed to change -DTPM_ENABLE=TRUE to

-DTPM2_ENABLE=TRUE. I

feel like a build-time check would've been a good way to communicate
this one, e.g.:

#ifdef TPM_ENABLE
#error TPM_ENABLE has been renamed to TPM2_ENABLE
#endif

commit 1631bb26ae991e530d3c96fe3161ea15144b358e
Author: Gary Lin <glin@...>
Date: Mon Jun 10 14:55:09 2019 +0800

OvmfPkg/README: Update the network build flags

The following network build flags changed due to the inclusion of
NetworkPkg/Network.fdf.inc.

Similar to the above, I needed to deal with this by setting
-DNETWORK_HTTP_BOOT_ENABLE=TRUE instead of

-DHTTP_BOOT_ENABLE=TRUE. It

seems like maybe an #error on the removed #define could've helped
here as well.

And finally:

commit 57783adfb579da32b1eeda77b2bec028a5e0b7b3
Author: Michael D Kinney <michael.d.kinney@...>
Date: Tue Jul 26 12:40:00 2022 -0700

OvmfPkg: Change default to disable MptScsi and PvScsi

With this types of change, it would be useful just to know this is
coming and why so I can decide to either notify users of the change
and/or override the default to avoid the regression. Would it be
possible to describe such changes in the release notes at
https://github.com/tianocore/edk2/releases - and, if not urgent,
perhaps #warn of deprecation in the source for one stable release
cycle?

-dann