search

dbos-inc / dbos-transact

The TypeScript framework for backends that scale
https://docs.dbos.dev
MIT License
291 stars 20 forks source link

Discussion on whether to use strict/non-strict versioning on the library dependencies #479

Closed demetris-manikas closed 1 month ago

demetris-manikas commented 1 month ago

Hi all. I came across https://github.com/dbos-inc/dbos-transact/pull/460#discussion_r1617448953. After a short discussion with @devhawk he advised that I start this issue and share my take on the matter.

In "short" this is it. :)

When to use strict versioning

  1. Lack of confidence in the development team of an imported library Sometimes library maintainers incorporate breaking changes in minor releases which is terrible but happens
  2. Few dependencies (which never happens in node)
  3. Lack of confidence on the tests

Pros of this approach

  1. Things break less frequently

Cons of this approach

  1. The need to upgrade a library sometimes causes a waterfall and fixing one thing leads to a lot more changes at once, which has its dangers, than when the upgrades are incremental
  2. Usage of outdated code.

When to use non strict versioning

  1. When developing a library (will be explained)
  2. Usage of the latest versions of libraries is considered a high priority
  3. Tests for the use of the library exist and are considered reliable

Pros of this approach

  1. Changes are incremental and cause trouble little by little instead of in big chunks
  2. Usage of the latest versions of libraries

Cons of this approach

  1. Things may break more often if proper tests of the libraries are not present

These lists are not exhaustive but contain the points I want to elaborate on.

So. Say I am a user of the dbos-transact library. I have my own strategy on how to handle dependencies. It is my responsibility and decision to make whether I will use strict or not versioning on dbos-transact so whether it uses strict versioning or not is irrelevant to me.

To wrap it up my approach is to use non strict version on all libraries excluding only libraries that are known to not be compatible with the product after some specific version (due to a bug or an api change that should not have happened but did). The reasons of using the strict versions should be well documented and tests that demonstrate the unwanted behaviour should be put in place.

This way the library uses the latest versions of as many libraries as possible and one can have a better overview of what has broken in the past and can easily try at a later time newer versions so as to at some point return to non strict versioning.

Anyway if the library will publish a faulty release is mostly related with how extensive and reliable the tests are. At some point a change of version will have to happen and npm packages are NOT to be relied upon for a long time (security alerts happen all the time) and at that point the tests are the ones that will have to be trusted about whether the new strict version is "OK" to use.

I realise I may be in the wrong here since a few major libraries that I checked all use strict versioning on ALL packages. Also there may be some really good arguments against non strict versioning that I am not aware of and I would very much like to hear them.

demetris-manikas commented 1 month ago

Closing due to inactivity