Versioning of the library

[toddb]

This library is tightly coupled to novu api versioning of the docker packages: see https://github.com/novuhq/novu/pkgs/container/novu%2Fapi

Tags are:

• dev
• prod
• latest
• version (eg 0.18.0)

Looking at the container repository:

• dev is usually ahead of prod (not always)
• prod looks to be always be latest
• prod always looks to be ahead of the last version tag
• prod is never tagged with a version <-- this seems strange IMHO

This library is tested before released on the production versioning of novu. Locally, it is tested on whatever version of the product the dev is using but most likely the docker-compose deployment script here. This script is not necessary up to date.

Final point, the developer build machine looks ideally to be a Mac which have arm64 yet the builds are amd64.

Furthermore, releases to production are both un-notified (eg in Discord) and not tagged.

Suggestions to versioning:

• have a copy of the docker-compose that has the version of the product tested against
• document clearly in the README the version tested against
• this library MAY need to follow versioning conventions so that when in nuget developers can see related upgrades (however, this convention is usual when the library is based on another nuget package and particularly a framework-type package)

[wh1337]

@toddb what if we coupled the versioning of this SDK to that of Novu?

e.g. v0.18.0 of novu-dotnet works with v0.18.0 of Novu

Thoughts?

[toddb]

@wh1337 My sense is to start with that. You might move to post pre-release numbers when it has stabilised and if it is an SDK rather than just client bindings library. The Sync code moves it away from simple bindings.

However, it is flawed too. What happens when 0.19 is released? There are no dependency specification in this library that requires the api (unlike a nuget package).

Bottom line is that the binding have to be maintained and updates responsive to be successful ;-) (Unlike what has happened this week!)

Probably the key here is that the document and the release notes need to explicitly show dependencies.

For example

0.2.2 <=0.17 next > 0.18

What I would like to see is an method that checks versions at runtime. I have documented how that happens and currently is not possible with the ApiKey. But that isn't hard to fix from the novu api maintainers.

[toddb]

Decision was to run independent versioning and clearly show dependencies in the readme.

[joaonlforte]

Hi @toddb @wh1337

my main concern with this is that it won't prevent future breaking changes that might be done on the api to be addressed by this SDK maintainers before the actual deployment.

Novu maintainers have to somehow communicate beforehand incoming breaking changes and liaise with this SDK maintainers before actually pushing things live (e.g Discord) or perhaps make proper use of SemVer to communicate that out.

Or

Breaking changes if not communicated out need to be backwards compatible

Not sure if a pre-prod env exists, but a potential workflow could be:

• Deployments to prod would always be tagged following a SemVer approach

  Major: breaking changes Minor: add/remove/update features Patch: patches & hotfixes

• Upon tagging (which would be vNext) a notification would be sent to a discord channel, and if there are breaking changes liaise the deployment with the SDK maintainers to ensure the changes are done and not break live environment

[toddb]

@joaonlforte thanks for that—great summary. I'll add for the record:

• they are still in pre-release (0.x.x)
• the API is difficult to runtime get its version /health-check is where the version lives and isn't even on ApiKey auth (let alone public anon)