search

NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
18.05k stars 14.08k forks source link

naming issues: dotnet-sdk dotnet-runtime dotnet-aspnetcore #260915

Open Plarpoon opened 1 year ago

Plarpoon commented 1 year ago

Notify maintainers @kuznero @mdarocha

After further discussion in this very same issue we decided to just add the -sts and -lts aliases. You can find here below the original "first post" with all the previous information.

Hi all, this is my first issue in here so I hope I am doing everything right.

I just noticed that there is a bit of confusion with the naming and packaging of .NET and I would have liked to discuss with you if there was a possibility of changing it to the same naming and versioning scheme that Microsoft uses.

I have noticed that at the moment we have a dotnet-runtime and dotnet-sdk packages that are running the 6.0 version, which is the LTS. I would like to call that one LTS.

We then have dotnet-runtime_7 and dotnet-sdk_7 which are actually the stable releases and shouldn't require to be mentioned the version 7 to be installed.

We then have dotnet-runtime_8 and dotnet-sdk_8 which except for the version number being different have the same exact schema as for the stable version but are in reality the preview version of version 8.

Same exact thing happening for the aspnetcore packages

I suggest we do as follows:

rename: dotnet-runtime => dotnet-runtime-lts dotnet-sdk => dotnet-sdk-lts dotnet-aspnetcore => dotnet-aspnetcore-lts

dotnet-runtime_7 => dotnet-runtime dotnet-sdk_7 => dotnet-sdk dotnet-aspnetcore_7 => dotnet-aspnetcore

dotnet-runtime_8 => dotnet-runtime-preview dotnet-sdk_8 => dotnet-sdk-preview dotnet-aspnetcore_8 => dotnet-aspnetcore-preview

I am obviously open to critique in case you think this is not a good idea but at the moment I genuinely believe this is the healthiest thing to do for several reasons.

1) We would keep naming parity with Microsoft making it clear at first sight what are we looking for when searching for packages. This is especially nice for very new users like me that are just discovering Nix for the first time 😃

2) The numbers are just going to increase and sooner or later we will have a big amount of version in our packages without a proper schema. With this change we would be able to always pin in our configuration files to always install either from the stable, preview or lts channel. If for some reason we need an old unsupported version we can always just install them by selecting "dotnet-sdk_6" like we have now!

I believe this would definitely improve the current situation, if I can be of any help please let me know! Ping me at will and we can chat here or any other social networks, I am almost always available!

Note for maintainers: Please tag this issue in your PR.

mdarocha commented 1 year ago

I don't see much value in aligning with Microsoft naming conventions, when that would mean a pointless breaking change in nixpkgs.

That means we should leave the no-postfix package names (ie. dotnet-sdk) to point to the latest LTS version like we already do.

We can then add new aliases without breaking changes:

We can also add the -lts alias now that I think about it, just don't change the no-alias names.

Plarpoon commented 1 year ago

While still thinking that my original proposal is better so in one go we are done with all changes I don't dislike your proposal at all, as that would still be a big improvement over the current situation.

eclairevoyant commented 1 year ago

I originally +1'd this based on some assumptions that turned out to be wrong. After double checking the MS site, I don't think the original progosal is even "Microsoft naming convention" but rather a bit made up.

As per this page, they do not have this -LTS or -Preview distinction; instead there is a list of versions, their support type (STS vs LTS) and the support phase. However, as of next month, we will have two LTS versions in active support (6.0 and 8.0), and an STS version (7.0) and calling 8.0 "preview" won't really make sense as it's both the current and the LTS.

I would be ok with warning users when they use the alias with no version, if we want to encourage them to use an explicit version, but not this change, which I believe will add more confusion over the coming years.

Plarpoon commented 1 year ago

If you look at the link you have yourself provided you can see with what I have confused myself, it used to be called "current releases" and now it is indeed called "sts". While preview is just what they call as umbrella term every phase before release. Thank you for correcting and updating me on that one!

But yes, having two active LTS versions would indeed be problematic, on that I fully agree with you, odd that they are doing that but that is besides the point.

I still think there are two different issues we should tackle on the dotnet releases.

1) Some packages have no version and some do. Which is inconsistent at least within nixpkgs itself.

2) There is no reliable way to always target the most recent stable version of dotnet without explicitly declaring the specific target version.

If you want to propose something that would tackle both issues I can even update the first post with your idea @eclairevoyant! I am trying to make this thing better so your ideas are as good as mine! 😃

eclairevoyant commented 1 year ago

Well thankfully there will only be one STS active at any point, so I think adding -sts is fine. LTS might be confusing, but -lts to point to the most-recent LTS, I would be ok with. And I suggest we not add -preview as that only applies to a short time frame prior to the release.

TLDR I'm ok with -sts and -lts, but I wouldn't add -preview

Plarpoon commented 1 year ago

I like your proposal, if anyone else agrees and has nothing against this change please write it as a comment and I will change the first post!

mdarocha commented 1 year ago

TLDR I'm ok with -sts and -lts, but I wouldn't add -preview

That seems fine to me :+1: 

1. Some packages have no version and some do. Which is inconsistent at least within nixpkgs itself.

Can you elaborate on that? Do you mean that the packages don't specify the SDK version, or that they use the aliases with no versions (ie. dotnet-sdk)? If the first, tha's fine, cause buildDotnetModule should use the latest LTS as the default (adding a -lts could help with maintaining that tbh). If the second, then true, that's a problem, and we should make an issue with a list of packages that have this problem, and work on how to best discourage such pattern.

eclairevoyant commented 1 year ago

The latter is not a thing in nixpkgs except in one package I could find (netcoredbg). For a second I also thought BeatSaberModManager had the issue, but quickly saw it's not even used in the nix expression.

Plarpoon commented 1 year ago

I will be very happy if this change gets applied, at least we can streamline the process quite a bit

mdarocha commented 1 year ago

So guess we can add the -lts and -sts aliases without much trouble - is everybody ok with that?

@NixOS/dotnet

Plarpoon commented 1 year ago

I think we are all in agreement @mdarocha, in such a spirit I have edited the first post to reflect exactly that change!

mdarocha commented 1 year ago

Cool. PRs welcome :D

Plarpoon commented 1 year ago

I have never opened a PR before in my life @mdarocha so if you see that I landed flat on my face can you please tell me?

https://github.com/NixOS/nixpkgs/pull/261695

l3m commented 11 months ago

So guess we can add the -lts and -sts aliases without much trouble - is everybody ok with that?

The -sts suffix is surprising. Because of how the dotnet release schedule works, it is only ever useful every other year. As new major versions are released at the end of the year, I will count them for the following year in this table.

Year Latest LTS STS
2021 5.0 3.1 5.0
2022 6.0 6.0 not meaningful
2023 7.0 6.0 7.0
2024 8.0 8.0 not meaningful

Not meaningful meaning that in those years, the last non-LTS version is out of support and generally everyone is advised to use the current LTS, not an outdated, out-of-support version.

Therefore, while -lts makes sense, I think it's better to either have no suffix for the latest dotnet version (as it might be LTS or not, depending on the year), or use -current, -latest or something like that.

I feel it doesn't make a lot of sense to have a -sts package, as what would it update to in the years where the latest version is an LTS? Having it point to the LTS seems surprising, but not updating to the latest version when a new version is released also seems suboptimal behavior.

mdarocha commented 11 months ago

@l3m I agree with you, adding only the -lts suffix seems like the most meaningful change here. We can also have -current for the latest .NET version, or we can agree to change the non-prefix version to the latest LTS whenever a new LTS releases (currently we mostly do it when ie. removing an EOL version)