-
Notifications
You must be signed in to change notification settings - Fork 564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NuGet package naming #627
Comments
👍 |
I agree with this too. We'll probably announce this upcoming change in the 1.13 release and put it in the READMEs, but not actually execute the change until 1.14. |
gbirchmeier
added a commit
to gbirchmeier/quickfixn
that referenced
this issue
Dec 30, 2024
gbirchmeier
added a commit
to gbirchmeier/quickfixn
that referenced
this issue
Dec 30, 2024
gbirchmeier
added a commit
that referenced
this issue
Dec 31, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
First of all, congratulations and thank you for finally publishing the project on NuGet 🎉
I fully understand that this is very subjective, however here are my 2 cents.
I think that the package IDs should have a different naming structure. Typically, dots in .NET world represent namespace or subproject separators. This means that QuickFIXn.FIX4.1 is logically divided into:
This is even worse with QuickFIXn.FIX5.0SP2:
I think that the project and assembly naming structure is much more clear, e.g:
QuickFIXn.FIX44
instead ofQuickFIXn.FIX4.4
QuickFIXn.FIX50SP2
instead ofQuickFIXn.FIX5.0SP1
So that FIX44 or FIX50SP2 represent the spec version as a single entity.
I understand that this would break backwards compatibility for those who already downloaded the packages but I strongly believe that it would be better to change the naming in the long run.
The text was updated successfully, but these errors were encountered: