Runtime: Update the Release Notes link for NuGet packages to point to .NET Core 2.1

Created on 25 Apr 2018  路  10Comments  路  Source: dotnet/runtime

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

area-Infrastructure-libraries documentation packaging

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.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.

All 10 comments

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.

fwlink updated. We really need to determine a meaningful and sustainable way to generate change info for packages updated each release.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

omariom picture omariom  路  3Comments

aggieben picture aggieben  路  3Comments

v0l picture v0l  路  3Comments

jkotas picture jkotas  路  3Comments

matty-hall picture matty-hall  路  3Comments