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.
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.
> 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.
>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.
Well that and you never need to run old versions of the software, rebuild old versions, deal with customers who have different versions, etc.
>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.
If you want to know when a build happened then it would be better to put that last. SemVer-based package systems typically do something like that with a fourth number. However, odds are you just want the latest in a series based on one code archive, so it only needs to be a simple sequence. People who need to know the date can consult other metadata to find out.
>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.
I think it's more complicated than this and thus TrunkVer only makes sense at the top level. If you apply it to a library, you better own the library and practically use a monorepo for your one app.
>For an app, it often makes sense to version an external API or data format independently of the app itself.
This only makes sense if you have multiple apps to deal with. Otherwise, the data format version practically is the app version and it would be pointless extra work for them to deviate.
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.