2 ms·

> That is to say, it communicates that there is no compatibility guaranteed between versions, and maintains the correct order between old and new versions. Whi

by 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
>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.

by thayne 2y ago

wakawaka28 2y ago

>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.