4 ms·

This is intended for use cases where it isn't necessary to communicate compatibility, such as a continuously deployed SaaS application or a user-facing applicat

by thayne 2y ago

This is intended for use cases where it isn't necessary to communicate compatibility, such as a continuously deployed SaaS application or a user-facing application, where backwards compatibly isn't a concern .

wakawaka28 2y ago
So what if this application has library dependencies developed by the same people? Don't you think that they would be tempted to use the same scheme to version those too, thus breaking any package manager?
- thayne 2y ago
  How would it break the package manager? In that case you would probably do one of the following: - use a monorepo, where dependencies on libraries don't have versions, they are just relative paths - the specified version is exact, if you want an update, you change the version dependency version constraint - you have CI automatically update such dependencies to use the latest version. - you don't use this versioning scheme for libraries
  - wakawaka28 2y ago
    Different packages demanding overly specific versions is an antipattern. I know you're bound to say, why not build more often? The trouble is that every package build probably needs testing, and there could be hundreds of individual dependencies that interact. Generally you cannot or at least would prefer to not have an application depend on multiple versions of a single package. Without SemVer it is very hard to find a solution. Even if you use CI to do all your builds, this scheme only really works if you're willing to build everything just because one thing updated its dependency. There is no concept of stability or long-term testing with TrunkVer. It's basically only suitable for a specific type of application and environment. It is not suitable for libraries. >use a monorepo, where dependencies on libraries don't have versions, they are just relative paths This is only an answer if there is one consumer of this repo and one major product. When a monorepo contains libraries, it is also the sole consumer of the libraries.
    - thayne 2y ago
      > It's basically only suitable for a specific type of application and environment. Absolutely. This isn't a replacement for SemVer, it is alternative to be used in cases where SemVer doesn't really make sense.
      - wakawaka28 2y ago
        I'd argue that SemVer makes sense for just about everything. If we were talking about something like a Linux distro, then sure I guess this is getting more reasonable. But for an app or library, especially one that generates data and/or has a programmatic interface, SemVer is better. SemVer might be a bummer when you have constant demand to immediately add stuff that is incompatible and you never have a stable version. It still works perfectly fine in that case however. That is to say, it communicates that there is no compatibility guaranteed between versions, and maintains the correct order between old and new versions. It probably also tells you approximately how many releases were between any two versions as well.
        thayne 2y ago
        > That is to say, it communicates that there is no compatibility guaranteed between versions, and maintains the correct order between old and new versions. Which is exactly what TrunkVer does. Every release increases the major version number. As long as the clock you use for the timestamp is monotonic. > It probably also tells you approximately how many releases were between any two versions as well. TrunkVer os useful in cases where knowing the time the version was created is more useful than knowing how many releases are between two versions. In particular, continuously deployed projects, where you might have multiple releases a day. > But for an app or library, especially one that generates data and/or has a programmatic interface, SemVer is better. For a library, I think it would be pretty rare for TrunkVer to make sense, unless maybe the only consumer of the library was an app that also used TrunkVer. For an app, it often makes sense to version an external API or data format independently of the app itself.
        wakawaka28 2y ago

by thayne 2y ago

wakawaka28 2y ago

So what if this application has library dependencies developed by the same people? Don't you think that they would be tempted to use the same scheme to version those too, thus breaking any package manager?

thayne 2y ago
How would it break the package manager? In that case you would probably do one of the following: - use a monorepo, where dependencies on libraries don't have versions, they are just relative paths - the specified version is exact, if you want an update, you change the version dependency version constraint - you have CI automatically update such dependencies to use the latest version. - you don't use this versioning scheme for libraries
- wakawaka28 2y ago
  Different packages demanding overly specific versions is an antipattern. I know you're bound to say, why not build more often? The trouble is that every package build probably needs testing, and there could be hundreds of individual dependencies that interact. Generally you cannot or at least would prefer to not have an application depend on multiple versions of a single package. Without SemVer it is very hard to find a solution. Even if you use CI to do all your builds, this scheme only really works if you're willing to build everything just because one thing updated its dependency. There is no concept of stability or long-term testing with TrunkVer. It's basically only suitable for a specific type of application and environment. It is not suitable for libraries. >use a monorepo, where dependencies on libraries don't have versions, they are just relative paths This is only an answer if there is one consumer of this repo and one major product. When a monorepo contains libraries, it is also the sole consumer of the libraries.
  - thayne 2y ago
    > It's basically only suitable for a specific type of application and environment. Absolutely. This isn't a replacement for SemVer, it is alternative to be used in cases where SemVer doesn't really make sense.
    - wakawaka28 2y ago
      I'd argue that SemVer makes sense for just about everything. If we were talking about something like a Linux distro, then sure I guess this is getting more reasonable. But for an app or library, especially one that generates data and/or has a programmatic interface, SemVer is better. SemVer might be a bummer when you have constant demand to immediately add stuff that is incompatible and you never have a stable version. It still works perfectly fine in that case however. That is to say, it communicates that there is no compatibility guaranteed between versions, and maintains the correct order between old and new versions. It probably also tells you approximately how many releases were between any two versions as well.
      - thayne 2y ago
        > That is to say, it communicates that there is no compatibility guaranteed between versions, and maintains the correct order between old and new versions. Which is exactly what TrunkVer does. Every release increases the major version number. As long as the clock you use for the timestamp is monotonic. > It probably also tells you approximately how many releases were between any two versions as well. TrunkVer os useful in cases where knowing the time the version was created is more useful than knowing how many releases are between two versions. In particular, continuously deployed projects, where you might have multiple releases a day. > But for an app or library, especially one that generates data and/or has a programmatic interface, SemVer is better. For a library, I think it would be pretty rare for TrunkVer to make sense, unless maybe the only consumer of the library was an app that also used TrunkVer. For an app, it often makes sense to version an external API or data format independently of the app itself.
        wakawaka28 2y ago