Comments (26)
Precisely what I was suggesting with regards to the new file. The additional index link fills in the picture.
from core.
I was also thinking about that. I think that's a good idea. We can then position the big releases.json
as a legacy option.
from core.
@martincostello We will make sure to only introduce the new format in a non-breaking manner. Any existing file must not be changed in a way not covered/permitted by JSON schemas. Adding fields might require an updated JSON schema, but should not break anyone.
Most changes will be in new files and should be introduced in parallel (maybe even marked as experimental for now) to gather input. That was at least already suggested by @leecow in a previous comment and I do like that approach.
from core.
Another point to mention is that the existing assets are machine generated and maintained, and the new ones will be as well. While we can iterate over ideas in 'experimental' PRs, the final PR implementing what we decide upon will be the result of tooling updates.
from core.
Being able to determine which repo(s) a CVE applies to would definitely have value. For example, a CVE related to WPF wouldn't be relevant for an ASP.NET Core app.
from core.
This sort of change would probably warrant a breaking-change announcement given that other people rely on that file for many things I'm not even aware of. Does Azure for example consume that sort of information?
The website is a given but I'm sure there are others.
from core.
This probably isn't that hard. We just need to create another link here:
core/release-notes/releases-index.json
Line 14 in f424bc4
Like:
{
"channel-version": "9.0",
"latest-release": "9.0.0-preview.1",
"latest-release-date": "2024-02-13",
"security": false,
"latest-runtime": "9.0.0-preview.1.24080.9",
"latest-sdk": "9.0.100-preview.1.24101.2",
"product": ".NET",
"release-type" : "sts",
"support-phase": "preview",
"latest-release": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/9.0/9.0.1/release.json",
"releases.json": "https://dotnetcli.blob.core.windows.net/dotnet/release-metadata/9.0/releases.json"
}
from core.
I understand your wording now.
My thinking is that we'd start this scheme with (for example) 8.0.3 and just move forward. Backporting the scheme would be nice, but it isn't clear that it is needed.
from core.
Throwing my hat into the ring as a consumer of this data.
I maintain a GitHub Action that consumes this data for automating patches: martincostello/update-dotnet-sdk.
I have various other things built on top of this data for automation purposes as well ("Is your internal application running the latest patch version of .NET?", "Download the latest two versions of the .NET SDK", "Is this version of .NET still in support?").
If things are going to be changed in a breaking manner, then for myself at least, I'd need a few weeks' notice of the final format (and ideally a side-by-side deployment period) to update all these things to the new data format.
from core.
For sure. We can do better. Also, if we were to come up with a short-link scheme, now would be the time to merge that in.
Another point is that almost no one benefits from 7 Previews and two RCs being included in these big files. That "weight" ends up being a substantial part of a release, particularly for the first year.
6.0 is at 6.0.27. That's 28 releases + 9 pre-release ones. That's 36, so pre-release ones are still 1/4 of the overall file. That's a waste, not to mention folks that only care about the latest release, and many of those likely only care about a very small subset of links.
from core.
I would love this change as I'm also a fan of smaller linked files over big files. It's definitely a breaking change that at least affects https://github.com/actions/setup-dotnet and most probably also the Azure pipeline.
I would also love if we use the breaking change to extend the JSON schema to include some more information that most probably benefit others like information on operating system support that is currently only maintained in the os-support.md
in a non-parsable format.
from core.
@richlander I did it testwise for .NET 8: Falco20019@c80f409
.NET 9 already started to add the preview1
folder below preview
while .NET 8 and prior only had all markdown files in there directly and a named subfolder in preview/api-diff
. I therefore would propose to clean this up as well. This also means that the release-notes
for previews will change, but since they are linked in the updated releases.json
, this should be fine.
My proposal would only leave release-date
, release-version
, security
and release-notes
in the releases.json
of the channel and move all other (and duplicate) everything that was previously an element of the releases
array. I added a release.json
(attention: singular) short-link to those elements instead.
from core.
One way to avoid the breaking change is to create a peer to releases-index.json
, with two options:
- Stop adding new releases to file at .NET 8 (remove .NET 9 from it).
- Continue publishing information to both flavors forever.
I don't think picking a date where we break the format is a good idea. Those plans never work.
from core.
Interesting ideas. A per-patch release file (e.g. /8.0.1/release.json) feels unappealing though that may be because I'm not understanding something.
@richlander, can you expand on what you mean by a 'peer' of releases-index.json?
To avoid breaking existing users (and there's a lot of them), perhaps we could create the release.json
(latest patch version only) alongside the releases.json
(cumulative, maintaining the major release history).
from core.
Backing up, the large files we produce seem like an anti-pattern to me, in two ways:
- Almost no one ever needs all (or most) of the data in our
releas.json
files. - Large JSON files should generally be avoided
As I said, I wrote a whole blog post on making reading these files efficient. It took a lot of effort. We shouldn't require our users to do that.
from core.
I don't disagree with any of that, though we have used the historical information in the 'complete' releases.json on a number of occasions. The clarifying question is along the lines of mitigating the breaking change while making this better for consumers. Something like:
- Implement a single, channel-located (e.g. https://github.com/dotnet/core/blob/main/release-notes/9.0/release.json) containing only the latest channel release information. Same schema as releases.json but only the latest release data.
- releases.json remains as-is but all documentation is updated to direct folks to the single file.
- Decide if and when the releases-index.json should be updated to point to the singleton providing a functional migration point to the new data for consumers that rely on the index for discovery.
from core.
we have used the historical information in the 'complete' releases.json on a number of occasions
I don't see why this would ever be a problem. If there was a 9.0 index, you'd be able to get all the same information.
from core.
We can also add another releases-index.json
per channel and link them in the main index. Than it's up to the caller if they follow the releases.json
or releases-index.json
link. No breaks involved.
I mean in addition to the proposed latest-release
link.
from core.
One example I prepared a couple days ago:
Just think of the 9.0/releases.json
to be named 9.0/releases-index.json
instead and the 9.0/releases.json
to look unchanged.
Will create a full draft including all touched files tomorrow since I'm out of office today.
Do you know if anyone relies on the structure of https://github.com/dotnet/core/tree/main/release-notes/8.0/preview and sub-folders? Because if not, we could align it with how .NET 9 uses a sub-folder for the preview1
to make it cleaner and have the release.json
in there next to the markdown per version.
from core.
Just think of the
9.0/releases.json
to be named9.0/releases-index.json
instead and the9.0/releases.json
to look unchanged.
Do you have a typo there? You mention 9.0/releases.json
twice.
We'd be very hesitant to change the 8.0 preview content. It is now in the past and putting effort into that or breaking people isn't desirable. We want to focus our efforts on forward-looking improvements.
from core.
No typo, maybe just written confusing. This was in reference to the linked commit. The change listed says 9.0/releases.json
but should be 9.0/releases-index.json
. I prepared it before that was discussed.
And the second mention meant that beside the name, the original one is kept as discussed here.
About .NET 8, we would still need to split it up at least for the versions under support in my opinion to make the index useful. But we can definitely do it non-breaking. Just wanted to make sure where the limits are 👍
from core.
I can have a look since I already did it test wise for the full .NET 8 and 9 releases. I think having .NET 6 through 9 should be enough, but as it just feels incomplete, I might try to generate the rest as well for completion sake.
Sorry if my wording is sometimes confusing. I’m no native speaker.
from core.
Sorry if my wording is sometimes confusing. I’m no native speaker.
Hearing you loud and clear.
Let's validate we have a good model for the in-support versions and then if you want to backfill date, you can.
from core.
I created a draft PR for discussion (only for .NET 8 and .NET 9, fully non-breaking). I also extracted the CVE part and introduced a separate index for it (open for discussion).
from core.
I extended my draft #9210 to include os-support
and cve
information as new data as this is something that I would love to have in a form that would help me generating some requirements for our customer documents. Basically making information that was previously only available in markdown files machine readable.
It would be great to hear from others if they miss something or have more input.
from core.
Now that we have fancy markdown releases notes in this repo, I'm wondering if we should move our CVEs from dotnet/announcements to a cves
directory (peer to 9.0
), with years as children. We'd then rely on our digest posts in dotnet/announcements to document the CVEs as a group. If folks really want us to keep on posting CVEs to dotnet/announcements, we can do that too.
We document CVEs as markdown, but don't share the markdown with you. That's not intentional, but a function of the way GitHub issues works. We publish markdown and you get HTML. A major goal of this new effort is to share markdown since it is a lot more flexible for re-use than HTML.
We're currently working on a cve.json
format as part of this project. Each CVE object would then link to the markdown file (with a regular GH URL, but switching that to the raw
variant should be trivial should that be desired).
Good idea?
I also took the opportunity to clarify the license of all of this content. I hope that's favorable.
- Markdown release notes: https://github.com/dotnet/core/tree/main/release-notes/9.0/preview/preview3
- CVE post: dotnet/announcements#303
- Digest post: dotnet/announcements#302
- License: https://github.com/dotnet/core/blob/main/release-notes/license-information.md
from core.
Related Issues (20)
- .NET March 2024 Update - .NET 8.0.3, NET 7.0.17, .NET 6.0.28 HOT 11
- Seemingly a typo in 6.0 sdk version on `releases-index.json`
- Dotnet Package for centos not installing from https://packages.microsoft.com/centos/8/prod/Packages/d/ HOT 12
- Poor benchmark performance all .NET versions HOT 5
- Unable to build xamarin project
- Intermittent error "The system cannot find the file specified" when instantiating X509Certificate2
- Release notes link broken HOT 1
- When is the .net pace of change going to slow down, or the length of time to support a given .net version going to increase? HOT 5
- بروزرسانی فایلها
- .Net on embedded platform HOT 1
- > where.exe dotnet C:\Program Files (x86)\dotnet\dotnet.exe C:\Program Files\dotnet\dotnet.exe HOT 1
- Failed to publish WASM client project for Linux
- .NET April 2024 Update - .NET 8.0.4, NET 7.0.18, .NET 6.0.29 HOT 5
- Getting Failed to fetch https://packages.microsoft.com/repos/edge/dists/stable for the last few hours HOT 2
- Is there an API to get the latest preview .NET SDK version HOT 7
- Failed to fetch https://packages.microsoft.com/repos/edge/dists/stable/main/binary-amd64/Packages.gz File has unexpected size HOT 3
- Package installation instructions are stale and need to be updated HOT 4
- Fedora 38 reaches end of life on 14 May 2024
- Add support for Alpine 3.20 HOT 1
- BEARSMITH8G HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from core.