Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Final branding for 17.11 #10270

Merged
merged 4 commits into from
Jun 20, 2024
Merged

Final branding for 17.11 #10270

merged 4 commits into from
Jun 20, 2024

Conversation

AR-May
Copy link
Member

@AR-May AR-May commented Jun 19, 2024

Final branding for 17.11

Also updated the public API version.

@AR-May AR-May requested a review from a team as a code owner June 19, 2024 17:54
@rainersigwald
Copy link
Member

Oh no, the Check Version Bump On Release Branches doesn't detect this case 😿

eng/Versions.props Show resolved Hide resolved
@AR-May
Copy link
Member Author

AR-May commented Jun 20, 2024

/azp run

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@AR-May
Copy link
Member Author

AR-May commented Jun 20, 2024

It seems like the build check test "CustomAnalyzerTest" started fails when there is a version bump. I will disable it here and in the main. Created issue #10277

@AR-May AR-May merged commit 1192b22 into dotnet:vs17.11 Jun 20, 2024
10 checks passed
JanKrivanek added a commit that referenced this pull request Jul 8, 2024
* Final branding for 17.11 (#10270)

* Final branding and public API version update

* Update the regex for initial commit detection

* Disable CustomAnalyzerTest

* Delete CompatibilitySuppressions file

* Add inter-branch merge flow file (#10274)

* Add version to BuildResult 2 (#10288)

Fixes #10208

Context
We are adding a version field to this class to make the ResultsCache backwards compatible with at least 2 previous releases (meaning the newer VS can read a cache created by older VS). The cache is not forwards compatible (older versions of VS cannot read cache created by newer versions). The adding of a version field is done without a breaking change in 3 steps, each separated with at least 1 intermediate release.

Execution plan:

1st step (done): Add a special key to the _savedEnvironmentVariables dictionary during the serialization. A workaround overload of the TranslateDictionary function is created to achieve it. The presence of this key will indicate that the version is serialized next. When serializing, add a key to the dictionary and serialize a version field. Do not actually save the special key to dictionary during the deserialization but read a version as a next field if it presents.

2nd step: Stop serialize a special key with the dictionary _savedEnvironmentVariables using the TranslateDictionary function workaround overload. Always serialize and de-serialize the version field. Continue to deserialize _savedEnvironmentVariables with the TranslateDictionary function workaround overload in order not to deserialize dictionary with the special keys.

3rd step: Stop using the TranslateDictionary function workaround overload during _savedEnvironmentVariables deserialization.

Changes Made
1st step from above description.

Testing
Unit tests, manual tests, experimental insertion

* Add CompatibilitySuppressions.xml

---------

Co-authored-by: AR-May <67507805+AR-May@users.noreply.github.com>
Co-authored-by: Farhad Alizada <104755925+f-alizada@users.noreply.github.com>
Co-authored-by: Jan Krivanek <jankrivanek@microsoft.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants