Skip to content
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 for DotNetLightning.ClnRpc has missing dependencies #224

Closed
rsafier opened this issue Aug 14, 2022 · 4 comments
Closed

Nuget package for DotNetLightning.ClnRpc has missing dependencies #224

rsafier opened this issue Aug 14, 2022 · 4 comments

Comments

@rsafier
Copy link

rsafier commented Aug 14, 2022

Missing two packages which are not public on Nuget so cannot try sample plugin code:
image

@knocte knocte changed the title Nuget package for DotNetLightning.ClnRpc has missing dependancies Nuget package for DotNetLightning.ClnRpc has missing dependencies Aug 16, 2022
@knocte
Copy link
Collaborator

knocte commented Aug 16, 2022

Hello @rsafier , thanks for reporting this problem!

I believe we have hit this problem before with the DotNetLightning nuget package, and we fixed it this way: c983074 .

So I guess we now need the same workaround for the DotNetLightning.ClnRpc project. Can you create a PR for this?

@joemphilips
Copy link
Owner

@rsafier
You are referencing old version of DotNetLightning.ClnRpc The newest version is defined by prefix version number. (in the same way with System.Commandline beta version management.)

This is the newest.
https://www.nuget.org/packages/DotNetLightning.ClnRpc/1.1.2-date20220806-0225-git-7c5fdbb

@knocte I believe it is a different problem. the latest version has no dependency for ResultUtils and PluginLogger

Recently I received a similar feedback from others, it seems that managing a package version with VersionPrefix is not user-friendly.
I must consider defining a publication flow with semantic versioning... probably with the way similar to NBitcoin.

@knocte
Copy link
Collaborator

knocte commented Aug 17, 2022

I guess it wasn't really @rsafier's fault because the version of the nuget package that fixed this issue was a pre-release. But I see that you just published a stable version (1.1.6) that contains the fix, so I guess we can close this now.

@knocte knocte closed this as completed Aug 17, 2022
@joemphilips
Copy link
Owner

Yeah, I guess I will create a new release manually every time there is a change so that this kind of confusion won't happen again.

At some point I should introduce more sophisticated/automated flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants