Currently, the release notes link in the published packages point to .NET Core 2.0.4:
https://github.com/dotnet/corefx/blob/a985f20d1a04d49ad086e3ef066565d05701cdaa/Packaging.props#L14
For example, see the preview2 System.Memory package which links to old release notes:
https://www.nuget.org/packages/System.Memory/4.5.0-preview2-26406-04
We should update it to point to the .NET Core 2.1 release notes (once they are a available). We have preview1/preview2 notes at the moment in:
https://github.com/dotnet/core/tree/master/release-notes/2.1
cc @ericstj, @joshfree, @weshaggard, @leecow, @danmosemsft, @karelz
Part of dotnet/runtime#23333 and dotnet/runtime#24501
@leecow @terrajobst can you guys get the fw links updated?
Using fwlinks isn't a very good solution here. The previously built packages use that fwlink, so if you update it to the latest release notes, you will be updating the 2.0.0 package to point to the 2.1.0 release notes.
Also, updating a URL in our source control for each release (think 4 branches: 1.0, 1.1, 2.0, 2.1) isn't really maintainable.
What if instead, we just pointed our nuget packages to the "root" release notes folder that we maintain? That way we wouldn't need to worry about updating the URL every release. The user gets a link to the root folder (https://github.com/dotnet/core/tree/master/release-notes), and yes needs to navigate to their specific version. But at least it is better than pointing them to the wrong version, which is what we have today.
Another option would be to have a templated URL for release notes, and we use the build version to build the URL:
Dotnet/core/releaseNotes/$(packageId)/$(version).md
I think the root release note page is sufficient. We do not need anything fancy especially right now. Assuming you agree @ahsonkhan would you mind offering A PR?
This seems to me to late for 2.1 though. Servicing.
@ahsonkhan would you mind offering A PR?
This seems to me to late for 2.1 though.
Since we are using fwlinks today, we could just change the existing fwlink to point to https://github.com/dotnet/core/tree/master/release-notes
Yes I'd expect to just update the fwlink. @leecow usually handles that and has the knowledge and permissions to update these.
@leecow can you please do this? Update https://go.microsoft.com/fwlink/?LinkID=799421 to point to https://github.com/dotnet/core/tree/master/release-notes
fwlink updated. We really need to determine a meaningful and sustainable way to generate change info for packages updated each release.
Most helpful comment
Using fwlinks isn't a very good solution here. The previously built packages use that fwlink, so if you update it to the latest release notes, you will be updating the
2.0.0package to point to the2.1.0release notes.Also, updating a URL in our source control for each release (think 4 branches: 1.0, 1.1, 2.0, 2.1) isn't really maintainable.
What if instead, we just pointed our nuget packages to the "root" release notes folder that we maintain? That way we wouldn't need to worry about updating the URL every release. The user gets a link to the root folder (https://github.com/dotnet/core/tree/master/release-notes), and yes needs to navigate to their specific version. But at least it is better than pointing them to the wrong version, which is what we have today.