Nobody calls them “translators”, that’s so silly. It’s a compiler, or transpiler (still a compiler).
Avoid using appeals to authority when discussing, it doesn’t make you look good. Even more-so when your authority is relatively mundane and you’re totally incorrect.
>Sure, but it does parse them and it does rightly understand that one is an newer version.
>
>That’s… compatibility.
Again, it isn't compatibility if the new scheme breaks every assumption that the old one had. You can't just say "The package manager wants 3 numbers so I'll stick 3 numbers in there. So it's compatible, see!" as the numbers you're putting in have no meaningful connection to the affordances of the other scheme.
I've spelled out some more concrete objections (including the fact that the date is arbitrary and that the hashes are not ordered according to authorship) here: https://news.ycombinator.com/item?id=42267051
You literally can shove three incrementing numbers into a version and call it compatible, as long as the numbers increment. That’s the only compatibility requirement.
The git hash is not an incrementing number. The date is not strongly tied to the actual code used in the build either. If I gave you a list of these TrunkVer numbers you couldn't tell me which ones are compatible, and neither can any package manager.
Package managers only work well with SemVer. They try to accept other schemes but anything but SemVer is an antipattern because of the inherent difficulties in figuring out what is actually going to satisfy a dependency.
Oh I read the most important thing, the original page.
>TrunkVer is a SemVer-compatible versioning scheme for continuously-delivered, trunk-based applications and systems that don't follow a release scheme.
It's not compatible with SemVer. I've explained why it isn't compatible in any sense multiple times now in various comments, probably most of them in reply to you.
>Repeat after me: the use case that fits this involves a need to integrate with a deployment system or tooling that expects semver versions.
Just because it fits doesn't mean it's "compatible". If you apply this TrunkVer scheme to a library, continuously deployed or not, the result is a disaster.
>I really don’t get what your obsession is with compatibility and package managers.
>the use case that fits this involves a need to integrate with a deployment system or tooling that expects semver versions.
A "deployment system" that you need to integrate with is most commonly a package manager.
>Repeat after me: the use case that fits this involves the need a versioning scheme that’s better than a meaningless incrementing integer
This may be more informative than an incrementing integer, but it is still not compatible with SemVer as the original page claims, and it is neglects many important considerations like variance between the build date, code version, and authorship date.
If you're going to reply to me again about this I suggest that you follow your own advice, because I've given fairly definitive objections to this scheme already:
>Stop and actually read what people are telling you before replying.
> If you apply this TrunkVer scheme to a library, continuously deployed or not, the result is a disaster.
Cool, except those are not systems or an applications are they?
> A "deployment system" that you need to integrate with is most commonly a package manager.
Completely incorrect for systems and applications.
> If you're going to reply to me again about this I suggest that you follow your own advice, because I've given fairly definitive objections to this scheme already
You did it again. You didn’t read.
> Repeat after me: the use case that fits this does not involve package managers, external distribution or any form of compatibility constraints.
My mentioning the specific case of a library does not invalidate anything else I said as it applies to applications. As I mentioned in another comment, applications (and "systems" which are often just an application bundled in a docker container or something) involve data, and SemVer communicates which versions are compatible with which.
>> A "deployment system" that you need to integrate with is most commonly a package manager.
>Completely incorrect for systems and applications.
I'm not wrong, but keep hitting the copium bro.
>Repeat after me: the use case that fits this does not involve package managers, external distribution or any form of compatibility constraints.
As I said, nearly everyone has compatibility concerns, or can develop them at any time. This is a short-sighted scheme. I can't deny that it "works" in some sense for a small number of people who are willing to make bad assumptions like that. But I cannot in good faith recommend it to anyone.
I'm not sure what you mean but if you're asking for a solution then SemVer is better than this in most cases. It has none of the issues I mentioned caused by TrunkVer.
>Do you think the deployment version is an appropriate format to convey compatibility in a system of that size and complexity? = I do not
OK I wonder how GitHub does self-hosting, migrations, etc. I assume they have bespoke upgrade scripts to migrate, and you might have to run them in a sequence. That doesn't mean SemVer is inappropriate. It just isn't going to help much.
>- Do you think it is deployed via a package manager like NPM or Bundle? = I do not
Although the site might not be deployed this way, libraries that interact with it probably are and they probably use SemVer. The only real argument against that is that you can't tell the API version supported from an unrelated SemVer number.
It’s not supposed to be informative. It’s not supposed to be parsed. It’s a version identifier. The date is much better than a commit hash or an opaque number for this.
Using semver for an external API is not a good fit at all. Compatibility is binary: it’s compatible or it’s not.
If it’s not compatible, it’s a new version.
Think on this a bit, and consider how this applies to a service as a whole, and you’ll finally understand what everyone has been telling you.
> That doesn't mean SemVer is inappropriate. It just isn't going to help much.
Irrelevant.
> Although the site might not be deployed this way, libraries that interact with it probably are and they probably use SemVer
>Using semver for an external API is not a good fit at all. Compatibility is binary: it’s compatible or it’s not.
Not true. You can be compatible with all APIs, adding no new features; you can add new features; and you can break existing features. These are the levels that SemVer can communicate. This makes as much sense for a web API as a binary library.
>Think on this a bit, and consider how this applies to a service as a whole, and you’ll finally understand what everyone has been telling you.
What all 3 of them? A vast majority of people prefer SemVer even if they detest the work that it generates. It's like a form of documentation.
You're not technically wrong but using the 3 numbers this way is in fact going to create problems for people trying to use this info. It means that you can never know if any version is compatible with others, and even if they were you could not easily link it.
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 .
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?
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.
It’s not creating a new problem that didn’t already exist.
In many situations at work, trying to follow SemVer would be a technical solution to a non-technical problem.
You know who your users are. Before you make any breaking change, you already have cross-product team meetings with possible executive buy in.
In those scenarios, by time you assign a version number, everyone is already on the same page. The actual version number is meaningless and conveys no useful information. Spending any time on deciding the version creates unnecessary toil.
It is creating a problem that didn't exist because using this instead of SemVer eliminates the option to communicate meaningful compatibility information.
>You know who your users are. Before you make any breaking change, you already have cross-product team meetings with possible executive buy in.
Generally none of these things are true. You don't know your users or how they intend to use your product. The executives certainly don't care about version numbers.
There are some cases where nobody cares about version numbers, which mainly occur when there is one or a handful of consumers of a product and they are likewise committed to very frequent releases. This is not how most distributable libraries work. Furthermore, people care less about version numbers when the numbers are not correctly assigned in the first place. If you aren't using SemVer then it's just an increasing sequence for the most part.
I know there are applications where version numbers don't matter. These are mainly singular websites and applications that have constant deployment. As I said, this version scheme is not compatible with SemVer because it uses a totally different concept and does not solve the same problems at all.
Well if you're trying to sell me "compatibility" you've got to do better than that. As I said in another thread, TrunkVer is not even guaranteeing a proper order for package versions, much less anything about the relationship between them. Your sales pitch is like trying to sell a USB 1.1 cable to someone who only has USB 4 devices or something. Can it fit? Maybe if you try hard enough. Will it do what you need? Nope.
> Well if you're trying to sell me "compatibility" you've got to do better than that
No, I’ve got to sell you what you want. And if you don’t want a compatibility relationship between package versions, then it’s an easy sell.
You’ve clearly not worked anywhere where this would be an easy sell. And that’s fine - it’s a specific kind of system that benefits from this, but don’t waste your time writing thousands of words when a simple “I don’t get why this is useful” would be enough.
>And if you don’t want a compatibility relationship between package versions, then it’s an easy sell.
Everyone has to think about compatibility, generally speaking, unless there is exactly one consumer of the product that is always running trunk and all their data is continuously migrated to the newest version. If you commit to using TrunkVer, then that's the only use case you can ever easily support, until you decide to switch to something like SemVer.
>You’ve clearly not worked anywhere where this would be an easy sell. And that’s fine - it’s a specific kind of system that benefits from this, but don’t waste your time writing thousands of words when a simple “I don’t get why this is useful” would be enough.
Whether or not it's an easy sell for a certain kind of user is a separate issue from the fact that it is unsuitable for most projects and libraries. It's also a separate issue from the fact that this version scheme does not deliver on its prominent claims of "compatibility".
I have probably worked at a company or two where TrunkVer could fly. But I would not advocate for it because I consider it a bad idea.
This is explicitly for software that's made an active choice to not guarantee 100% compatibility between successive releases, so that outcome is a feature.
well, yes, this is the only safe thing to do. The build system has no information what has changed since last build - maybe it was a complete interface rewrite - so it does the safe thing.
> The criminal enterprise used a complex international IT system to “capture and resell” live programming and other on-demand content from companies including sports broadcaster DAZN, Netflix, Amazon Prime, Paramount, Sky and Disney+, prosecutors said in a statement on Wednesday.
My experience: I put parquet files on R2, but HTTP Range requests were failing. 50% of the time it would work, and 50% of the time it would return all of the content and not the subset requested. That’s a nightmare to debug, given that software expects it to work consistently or not work at all.
Seems like a bug. Had to crawl through documentation to find out the only support is on Discord (??), so I had to sign up.
Go through some more hoops and eventually get to a channel where I received a prompt reply: it’s not an R2 issue, it’s “expected behaviour due to an issue with “the CDN service”.
I mean, sure. On a technical level. But I shoved some data into your service and basic standard HTTP semantics where intermittently not respected: that’s a bug in your service, even if the root cause is another team.
None of this is documented anywhere, even if it is “expected”. Searching for [1] “r2 http range” shows I’m not the only one surprised
Not impressed, especially as R2 seems ideal for serving Parquet data for small projects. This and the janky UI plus weird restrictions makes the entire product feel distinctly half finished and not a serious competitor.
Of course not, and it’s completely correct behaviour: if a server advertises it supports Range requests for a given URL, it’s expected to support it. Garbage in, garbage out.
It’s not clear how you’d expect to handle a webserver trying to send you 1Gb of data after you asked for a specific 10kb range other than aborting.
"Conversely, a client MUST NOT assume that receiving an Accept-Ranges field means that future range requests will return partial responses. The content might change, the server might only support range requests at certain times or under certain conditions, or a different intermediary might process the next request." -- RFC 9110
Sure, but that’s utterly useless in practice because there is no way to handle that gracefully.
To be clear: most software does handle it, because it detects this case and aborts.
But to a user who is explicitly asking to read a parquet file without buffering the entire file into memory, there is no distinction between a server that cannot handle any range requests and a server that can occasionally handle range requests.
Okay! Apart from sanitation, medicine, education, wine, public order, irrigation, roads, the fresh-water system and public health, what have the Romans ever done for us!?
Oh boy. It’s rare to see such confidence mixed with such nonsense.
reply