Hacker News Reader

Comment by jrochkind1 | Hacker News Reader

This is sarcastic/satire, pretty sure? Not sure all the comments are catching that.

When I have to use a 0.x-versioned package because it's a (hard or soft) dependency of some popular framework/platform/tool that "everyone" is using... I feel personally insulted. Like they're saying "no, we're not willing to say this is production-ready, we're not willing to say that we're not going to break backwards compatibility every month or so in a way you can't predict from the version number so can't do automated dependency updates ever, but, hey, everyone else is using it, what's your problem?"

It's like the ultimate embrace of the typical HN "open source maintainers owe you nothing and you should expect nothing of them" argument. Which is true, but if all packages literally made no effort to meet user needs and we had learned to expect nothing from them, we would never be using open source....

View on HN

> When I have to use a 0.x-versioned package because it's a (hard or soft) dependency of some popular framework/platform/tool that "everyone" is using... I feel personally insulted. Like they're saying "no, we're not willing to say this is production-ready, we're not willing to say that we're not going to break backwards compatibility every month or so in a way you can't predict from the version number so can't do automated dependency updates ever, but, hey, everyone else is using it, what's your problem?"

Wait, insulted by whom? The package developers are surely not obliged to develop their package to a standard that satisfies you, and it's hardly their fault if someone else feels that their package is useful enough to integrate it into something popular. Insulted by the popular framework that uses it … maybe, but you are not willing to forgo the use of 0.x-versioned packages even when it is a point of principle for you, so why should the developers of those frameworks forgo it when it is not a point of principle for them?

Then don't use that software if prod if that’s how you feel. The project is literally telling you “this will change and isn't _api_ stable yet. I don’t see how that’s the project’s fault. Maybe if they’re advertising themselves as production quality but won’t commit to a 1, fine.

Do you think that's appropriate for React Native? Many of the others on their list of notable projects would probably be considered "production" quality if you asked the average dev and didn't mention the version number.

I would think that's appropriate for React Native. It depends where you draw the line of "production-ready", but React Native falls short on a number of criteria (stability or bug-freeness for example). It's just a damn useful tool, despite its many shortcomings.

to me production-ready means ready to be used in production; If you and many people consider it useful enough to be used in production despite shortcomings, and are doing so, if the developers are aware of that and don't discourage it (does any react native documentaiton anywhere say not to use it in production?), and perhaps encourage it... it sounds production-ready to me.

So other people are the only ones who know when my project is done? And if people start using my project in production I have to immediately bump the version from 0.4 to 1? This doesn't make any sense…

Right, I'm with you. I think maybe the whole "we should all version the same way" thing probably isn't the right answer to "how do we know when it's safe to upgrade" question.

What is there to commit to though? There are enough integers to keep bumping the major version every day indefinitely if that's how often your api changes. Also, no one forces you to support 'deprecated' versions, and the rate of deprecation is completely in the hands of maintainers. It's just nice to have some indication of what's going on between versions.

If something is 'production ready', it's definitely past the '0.y' stage by definition. At least if you actually stick to semver, as '0.y' is explicitly defined as reserved for initial development.

Because a major version of 1.0+ carries the social implication of updates and stability, even if that's not written in the SemVer spec. Many projects want to avoid even the impression of stability

This is fine, as long as those projects don't also encourage people to use them in docs and fancy marketing websites. That's just double faced.

So let’s say you start a project, get 70% there, it’s version roughly 0.7. The project blows up, people get interested, lots of attention is paid to the periphery. Everyone is now using your project but it’s still missing 30% of what you’d consider necessary to be feature complete. What do you do?

That's the big misunderstanding here, isn't it? That software must be 'done', 'finished', 'feature complete', etc, in order to have major version number greater than 0.

I would (I hope), release version 1.0 soon after I notice people actually using the software, document the existing API, keep releasing new features as minor version updates (1.x), and occasionaly do a major version bump if I see that I must break the existing APIs. As semver prescribes.

OP: I have issues with the phrase "open-source devs don't owe you anything"

Reply: OPEN-SOURCE DEVS DON'T OWE YOU ANYTHING!!!

Come on, at least try to engage with what's being said.

That’s not what I said, maybe ready my comment again.

OP: I have a problem with open source projects where the marketing and version number don’t match. If it looks like a prod, and smells like a prod, it’s a freaking prod. You owe us a 1.0.

Reply: Okay, but maybe don’t go gobble up any project out there that has a nice landing page and docs and get fooled into thinking it’s a prod. The devs are probably using semver to try and communicate with you. If the project smells like a prod to you but is only version 0.8 and that makes you antsy, then don’t be part of your own problem. Don’t use it in prod. Simple.

Also plenty of software is stable enough to be used as 0.8 even in prod even if it’s not feature complete and the maintainers don’t consider it 1.0.

If you want your 0.8 to magically become a 1.0, have you considered sponsoring the project so that some devs can work full time on it? Hmm.

From the About page:

> ZeroVer is satire, please do not use it.

Unfortunately, from the main page it's clear everybody does anyway.

> open source maintainers owe you nothing and you should expect nothing of them

I tend not to release projects just because I think people should expect something from me if I do.

On another note, I'm totally down to accept that OSS projects be malleable, but it does irk me when someone:

1. brags a ton about their project just to find it's really not that great or

2. changes things with almost no concern for who it will affect and how or

3. refuse to change things for some ideological reason when tons of people are asking for it ("that's not the right way to do it!" "you don't know my project")

You never have to use a 0.x-version package even if "everyone" is using it, this is like another ultimate HN "I'm forced to do what everyone else is doing and I hate my own choices". If it's just an indirect usage via dependency of a stable package, then it doesn't matter, the stable package itself is responsible for its stability.

We use open source because through either corporate incentive or altruistic passion, some packages do put in the effort to meet user needs. That happens whether you think they owe you anything or not, which they don't. All you achieve by raising the floor of expectation is discourage non-production-ready open source contributions, which I think are still valuable regardless of how unstable they may be.

Reply on news.ycombinator.com