4 ms·

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

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