[Windows] Move buildId to latest

[marcwrobel]

See also #2296 and #2340.

[Evernow]

I'm personally against this sort of change that very obviously breaks how others may be using the API already, as it renames buildId, especially as I see no benefit to the end user.

[captn3m0]

The API is still in Alpha, so we can make breaking changes. Moreover, the stability guarantee shouldn't apply to products themselves, just the overall API - we should be allowed to make changes like dropping codenames, or adding/removing columns for products still.

buildId was added in the API around October in #1651, the field used cycleShortHand earlier (which was also incorrect, imo).

+1 to just switching to latest, since that makes it the most clear and usable.

[marcwrobel]

I'm personally against this sort of change that very obviously breaks how others may be using the API already, as it renames buildId, especially as I see no benefit to the end user.

I understand your point about breaking the API, really. It's a pain in the a** when API definition changes. This is why we had requests for API versioning (#2331, #2066) and I hope we will go in the right direction with #2080 (do not hesitate to give me your feedback on this PR @Evernow !).

But I do not agree with the I see no benefit to the end user part because:

• buildId is not a "standard" field in the first place (only used for Windows / Windows Server), so it requires custom handling by API users anyway (if their tool is not consuming only the https://endoflife.date/api/windows.json endpoint of course).
• The point of this PR (and of [windows][windowsserver] Add Build ID #2296 in the first place) was to make this buildId visible in the main table on https://endoflife.date/windows, which is not possible with a custom field.

So I think it makes things go in the right direction, but unfortunately it breaks things for API users. But hopefully it was made available in the API quite recently and we are still in alpha.

[marcwrobel]

PR ready for review.

[usta]

Please remove /en-us/ or /fr-fr/ parts in url , website will relocate user to its language directly

[marcwrobel]

Please remove /en-us/ or /fr-fr/ parts in url , website will relocate user to its language directly

Done. Sorry I missed it.

[captn3m0]

LGTM. We should look at automating this next.

[marcwrobel]

LGTM. We should look at automating this next.

Yep, but it would be difficult for the time being. I did not find any "centralized" source of Windows releases (except maybe Wikipedia) and anyway we are only tracking the buildId which looks stable (i.e. never updated).

I noticed during my search that :

• Microsoft have removed the 10.0 in the buildId lately (see https://learn.microsoft.com/windows/release-health/release-information),
• Microsoft now publishes a list of build, which is derived from the buildId (see also https://learn.microsoft.com/windows/release-health/release-information).

Don't know what to do with those informations.

[Evernow]

Yep, but it would be difficult for the time being. I did not find any "centralized" source of Windows releases (except maybe Wikipedia) and anyway we are only tracking the buildId which looks stable (i.e. never updated).

I tried tackling this for a personal project of mine and came to the same realization, the closest thing I found is FIDO which is a tool Rufus uses for downloading ISOs.

However there are flaws with this, such as having to parse in output that could potentially change, it having problems from time to time and it not giving exact dates.

The powershell script may have its own API you can access, but when I used to use it I parsed it using this: https://github.com/24HourSupport/CommonSoftware/blob/main/.github/workflows/fidoparser.py#L21

On a different topic, sorry forgot to respond earlier to your statement, I agree with you, this looks good to me,

[usta]

LGTM

[BiNZGi]

LGTM