Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
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
9 changes: 6 additions & 3 deletions pkg/Microsoft.Private.PackageBaseline/packageIndex.json
Original file line number Diff line number Diff line change
Expand Up @@ -417,7 +417,8 @@
"2.0.1",
"2.1.0",
"3.0.0",
"3.1.0"
"3.1.0",
"3.1.1"
Copy link
Member

Choose a reason for hiding this comment

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

I suppose we also want to bump up the baseline below to make sure we use the latest package reference in case somebody depends on this one right?

Copy link
Author

Choose a reason for hiding this comment

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

we never changed the baseline before for any of the published packages. is something different about this one ?
cc @ericstj

Copy link
Member

Choose a reason for hiding this comment

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

that may be a problem with our process. The baseline version will make sure that if any other package has a package reference to this package, it will force the version to be at least the baseline version (or whichever version has the assembly version in package that you are referencing). You don't always want to do this as you sometimes don't want to pull in many other packages by updating one reference, but for these OOBs it may make sense to update baseline version as well. I'll let @ericstj comment on what the right thing to do here is.

Copy link
Member

Choose a reason for hiding this comment

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

Originally POR was to never baseline (even across releases). We added baselining in 1.1 because folks wanted a consistent wave of packages. We have only selectively baselined in servicing when we wanted to ensure a dependency is updated as part of updating the depending package, but we've tried to keep our servicing independent. One thing we could consider was to update baseline for security updates.

Copy link
Author

Choose a reason for hiding this comment

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

@ericstj do u mean to bump up the baseline for all the packages which were serviced in security releases or just the package if any with the security fix ?

Copy link
Member

Choose a reason for hiding this comment

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

If we ever ship a security fix in package A version X, it makes sense to set the baseline for package A to version X.

Copy link
Author

Choose a reason for hiding this comment

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

okay cool understood. most of our security fixes until now have been in the shared framework

],
"BaselineVersion": "3.1.0",
"InboxOn": {}
Expand Down Expand Up @@ -1536,7 +1537,8 @@
"4.6.1",
"4.7.0",
"4.8.0",
"4.8.1"
"4.8.1",
"4.8.2"
],
"BaselineVersion": "4.8.0",
"InboxOn": {
Expand All @@ -1560,7 +1562,8 @@
"4.5.0.1": "4.6.1",
"4.6.0.0": "4.7.0",
"4.6.1.0": "4.8.0",
"4.6.1.1": "4.8.1"
"4.6.1.1": "4.8.1",
"4.6.1.2": "4.8.2"
}
},
"System.Data.SqlXml": {
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -3,8 +3,8 @@
<PropertyGroup>
<!-- We use the PackageVersion property defined in Packaging.props for the Prerelease packages which are using it to be built -->
<_PreReleasePackageVersion>$(PackageVersion)</_PreReleasePackageVersion>
<PackageVersion>3.1.0</PackageVersion>
<ServiceModelVersion>4.8.1</ServiceModelVersion>
<PackageVersion>3.1.1</PackageVersion>
<ServiceModelVersion>4.7.0</ServiceModelVersion>
<!-- We don't need to harvest the stable packages to build this -->
<HarvestStablePackage>false</HarvestStablePackage>
</PropertyGroup>
Expand All @@ -30,7 +30,7 @@
<PrereleaseLibraryPackage Include="System.Data.OleDb" />
<PrereleaseLibraryPackage Include="System.Data.SqlClient">
<!-- SQL client defines its own version, higher than rest of master -->
<Version>4.8.0</Version>
<Version>4.8.2</Version>
</PrereleaseLibraryPackage>
<PrereleaseLibraryPackage Include="System.Drawing.Common" />
<PrereleaseLibraryPackage Include="System.Diagnostics.EventLog" />
Expand Down
4 changes: 2 additions & 2 deletions src/System.Data.SqlClient/Directory.Build.props
Original file line number Diff line number Diff line change
Expand Up @@ -2,8 +2,8 @@
<Import Project="..\Directory.Build.props" />
<PropertyGroup>
<!-- Must be kept in sync with pkg\Microsoft.Windows.Compatibility\Microsoft.Windows.Compatibility.pkgproj -->
<PackageVersion>4.8.1</PackageVersion>
<AssemblyVersion>4.6.1.1</AssemblyVersion>
<PackageVersion>4.8.2</PackageVersion>
<AssemblyVersion>4.6.1.2</AssemblyVersion>
<!-- Downgrade the Assembly Version to match RTM in order to have System.Data shim to still
typeforward to RTM version instead of servicing version -->
<AssemblyVersion Condition="'$(TargetGroup)' == 'netcoreapp'">4.6.1.0</AssemblyVersion>
Expand Down
6 changes: 6 additions & 0 deletions src/packages.builds
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,12 @@
<Project Include="$(MSBuildThisFileDirectory)..\pkg\Microsoft.NETCore.Platforms\Microsoft.NETCore.Platforms.builds">
<AdditionalProperties>$(AdditionalProperties)</AdditionalProperties>
</Project>
<Project Include="$(MSBuildThisFileDirectory)System.Data.SqlClient\pkg\System.Data.SqlClient.pkgproj">
<AdditionalProperties>$(AdditionalProperties)</AdditionalProperties>
</Project>
<Project Include="$(MSBuildThisFileDirectory)..\pkg\Microsoft.Windows.Compatibility\Microsoft.Windows.Compatibility.builds">
<AdditionalProperties>$(AdditionalProperties)</AdditionalProperties>
</Project>
</ItemGroup>

<ItemGroup>
Expand Down