Calendar Versioning (CalVer, YYYY.Release.Patch) fulfills the same need and you can see it in practice with Jetbrains (e.g. the latest version of IDEA is 2025.3.6).
The only difference is Jetbrains uses YYYY.R for marketing, see: "What's new In 2025.3"[1]
I've been using calendar versioning quite happily with my mobile apps for a while now. It reduces the amount of angst and bike-shedding that comes along with otherwise rev'ing a major version number.
>But before I did so I researched first. I asked a few instances to analyse the project in terms of gains of complexity, stability, testability, etc., and while (obviously) stability would drop (no types in Ruby) it’s not that awful (Sorbet has types in Ruby!).
Is it not a rage-bait argument to say that not having types implies less stability?
If I followed, Rust's memory safety guarantee means sacrificing roughly ~3% performance with some worst case paths being ~15% (compared to C++ performance)?
Ah, I was using GH's webui instead of downloading to view the PDF and it stopped loading at slide#47...rereading it now paints a much better picture. Thanks!
Is it too much to ask for a not-vibe-coded billing system? In my opinion, we need better systems to hold these companies accountable as I don't believe the $20/dispute they're paying means much given how common other customers are complaining about billing irregularities just in this thread alone.
Is there a name for the practice of embedding a completely unrelated video into the middle of an article? I find this practice to be so mystifying. Does that work on readers?
Fairly accurate, you can only get support if you're using their cloud product.
"We no longer support paid, open-source deployments and it is no longer possible to buy licenses for self-hosted versions - we instead recommend migrating to PostHog Cloud." - from: https://posthog.com/docs/self-host
OP's ask was: "Is this another one ... where open source is used more as a marketing gimmick"
My original comment wasn't intended to indicate that there is an obligation to provide support. The deliberate choice to: a) not offer paid support for open-source deployments, and b) sunsetting the Kubernetes deployments in favor of their cloud version, is a signal that shows PostHog doesn't /really/ want you to be running the software in a self-hosted manner.
Just look at the "Open-source hobby deploy" (from the README in git) which calls out that it "should scale to approximately 100k events per month" but their cloud offering gives you 1 million events per month for free. What is the point of the hobby "deploy"?
Back to OP -- my answer is yes, this is a source-available service that you can modify and play around with locally. The source and documentation behind the operations of PostHog aren't available.
The math didn't add up for us (I work at PostHog). At the rate we were scaling, we would have needed an entire call center's worth of highly trained Kubernetes support engineers to debug everyone's "my pods just died" / "Kafka just stopped" / "what is Zookeeper" problems.
This stack isn't straightforward to manage, and we couldn't crack the code of doing it at scale for other people without even having access to their systems. There was no malicious intent.
I disagree with the notion that oss is used as marketing bait.
a) offering paid support for bespoke selfhosted installations is an entirely different business model than building a managed service on your oss offering
b) maintaining k8s/helm charts is work - who is paying for that? The selfhosting users certainly aren’t and usually contributions are not enough and even then still need reviews.
You think it’s a deliberate choice.
Yes it’s the choice between going out of business and continuing.
What a wild story...it's crazy to think that we have 1080p emulator video (https://www.youtube.com/watch?v=EufWGcflwjQ) without having the underlying rom ever ending up on the internet.
Calendar Versioning (CalVer, YYYY.Release.Patch) fulfills the same need and you can see it in practice with Jetbrains (e.g. the latest version of IDEA is 2025.3.6).
The only difference is Jetbrains uses YYYY.R for marketing, see: "What's new In 2025.3"[1]
https://www.jetbrains.com/idea/whatsnew/2025-3/
reply