Skip to content

Fix Microsoft.Extensions.DependencyModel AssemblyVersionInPackageVersion #36301

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.

Sign up for GitHub

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

Merged
joperezr merged 1 commit into from
May 13, 2020
+2 −1
Merged

Fix Microsoft.Extensions.DependencyModel AssemblyVersionInPackageVersion #36301

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion src/libraries/pkg/baseline/packageIndex.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -549,7 +549,8 @@
"BaselineVersion": "5.0.0",
"InboxOn": {},
"AssemblyVersionInPackageVersion": {
"3.1.4.0": "5.0.0",
"3.1.3.0": "3.1.3",
"3.1.4.0": "3.1.4",

@Anipik Anipik May 13, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dont we increment the last part in the servicing releases ?

@joperezr joperezr May 13, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe but this is just reacting to a package serviced in release/3.1 which was not yet part of libraries so may use different versioning

@eerhardt eerhardt May 13, 2020

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m not sure I understand the question.

This library was not part of corefx. This is the first release it is being built using the “corefx/libraries” packaging infrastructure.

@joperezr joperezr May 13, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

He is saying that usually in servicing we only increment the last part of the assembly version, so package 3.1.4 should have had assembly version 3.1.3.1 instead of 3.1.4.0, but that wasn’t a decision made on this PR, this is just reacting to what already happened in servicing

@Anipik Anipik May 13, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes i should have been more clearer, i meant to ask if the versioning scheme used here is on purpose or just a mistake in packaging (nothing wrong with this pr)

@joperezr joperezr May 13, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Anipik keep in mind that at least in release/3.1 this package is being built on a different repo (coresetup) which means that they were using a slightly different infrastructure and were possibly not following the same versioning guidelines we do in corefx. Now we have moved it to runtime it should start following conventions starting from 5.0 release

"5.0.0.0": "5.0.0"
}
},
Expand Down