[HN Gopher] ZeroVer: 0-Based Versioning
___________________________________________________________________
ZeroVer: 0-Based Versioning
Author : polm23
Score : 538 points
Date : 2021-08-12 09:51 UTC (13 hours ago)
(HTM) web link (0ver.org)
(TXT) w3m dump (0ver.org)
| everyone wrote:
| Oh its a joke? Poe's law was in effect for me.
| hzhou321 wrote:
| On the other hand, I am also quite annoyed that some projects do
| yearly major version after 1.0.
| amarant wrote:
| So why is react native still 0.x? Is it really still unstable
| after 6 years? Seems like they should settle on a API already...
| ziggus wrote:
| My versioning scheme is based on UNIX timestamps of releases, all
| concatenated together. Something like this:
|
| {major release timestamp}.{minor release timestamp}.{last patch
| timestamp}, which winds up like: 1542051468.1576431468.1613410668
|
| Very clear and easy for users to understand.
| NetOpWibby wrote:
| This seems ironically complex. If starting from zero, why have
| any dots at all? Don't make sense.
|
| I'll continue using ChronVer. https://chronver.org
|
| (Full disclosure, this is my site)
| exabrial wrote:
| If it really bothers you, I could write a script that subtracts 1
| from semver compatible version numbers on checkout, and
| increments on push.
| makach wrote:
| ...wait, this is a joke?! ..right?
|
| *edit: yes, published 1 april 2018
| ohdannyboy wrote:
| The idea itself was not obviously satire to me, sadly. Once I saw
| the list I realized they were making fun of using version 0 as an
| excuse for unfixed bugs.
| eurasiantiger wrote:
| Shenanigans aside, 0.x versioning is commonly used when
| developers cannot (yet) make any guarantees about backwards
| compatibility between minor releases.
| dilap wrote:
| At the risk of sucking the fun out of a pretty funny joke, I
| think the underlying subtext is that established projects are
| failing to "grow up" -- i.e., that established, depended-on
| projects are hiding under the shield shield of a youthful 0.x
| version, when really, given how popular, old, and depended-on
| they are, they should embrace that responsibility and grow into
| 1.something.
|
| (Though, on the other hand, maybe it's more just honest
| signaling of expectations. "We are a 0.x project, we value
| developer speed and a clean code-base more than backcompat or
| stability for users. We will NEVER grow up!" We could call it
| Peter Pan versioning.)
| eurasiantiger wrote:
| I'd hazard a guess that many of those projects are for
| environments that cannot guarantee stability, so the
| instability kind of rolls over to the projects themselves.
| robertlagrant wrote:
| I think they just don't care about marketing. 1.0 being grown
| up is a marketing perspective. You could start at 2.0 and not
| be "grown up" in the slightest.
| inanutshellus wrote:
| This is an unhelpful argument. It effectively says "meaning
| doesn't exist". I could also version my software
| "chicken.banana.guacamole" and be pissed that nobody
| understood that meant it was enterprise-and-production-
| ready. Point is, there's a convention and this satire
| website is pointing out obviously-wrong cases of mis-
| versioning.
| robertlagrant wrote:
| > It effectively says "meaning doesn't exist".
|
| No.
|
| It says that there's no universal agreement on this one
| thing, and while if you want to sell to certain people
| you should tailor your versioning appropriately, there's
| zero point in assuming a single interpretation. If I use
| CalVer some people who think there's only one way to do
| this may assume the product has had 2021 major version
| releases.
|
| That would be a silly assumption.
| pornel wrote:
| Once a project has been out for years, and has thousands or
| millions of users, it's not in the experimental phase any more,
| regardless of what the version number claims.
|
| Similarly to https://www.hyrumslaw.com
| eurasiantiger wrote:
| It has nothing to do with experimental status; rather, some
| efforts like React Native concern platforms that constantly
| introduce new OS versions with new and deprecated APIs. It
| doesn't make sense to pin versions to device generations when
| there are half a dozen different vendors to account for: if
| changes to one platform mandate breaking changes, all
| platforms would be affected anyway, and any platform can
| change at any time. Since new devices are first adopted by
| people with lots of money, developers have an incentive to
| stay as current as possible, so the point of pinning to
| device versions or generations is completely moot.
| pornel wrote:
| In semver terms that means increasing semver-major. Instead
| of 0.x.y you do x.y.z. There's no rule in semver that says
| you need to stay on 1.x forever.
| necovek wrote:
| I did not find it a very compelling joke until I checked out the
| list of projects: some running their "0.*" versions for 10+
| years, and many a familiar name in there too -- ouch!
|
| That made me laugh out hard :D
| soraminazuki wrote:
| Neovim is listed as a "notable ZeroVer project" and yet it has a
| 1.0(!!) milestone in the GitHub project page.
|
| https://github.com/neovim/neovim/milestones
| colonwqbang wrote:
| > 0% complete
|
| > No due date
|
| > Last updated over two years ago
|
| Looks like a classic case of ZeroVer!
| quickthrower2 wrote:
| Replace "case" with "practitioner" please. It's not a
| disease!
| jrochkind1 wrote:
| Are you sure about that?
| mjburgess wrote:
| Seemed like a strange joke until you see the table,
| Project Stars Released Releases Current Version 0ver
| years React Native 96,747 2015 359
| 0.65.0-rc.2 (2021) 6.3
|
| ...lol
|
| God forbid tor, sklearn, react-native release a v1 -- people
| might _expect_ things!
| vjeux wrote:
| For React Native we do ~monthly releases and just increase by 1
| each time. It's a train model this way people know when their
| changes will get released. I guess we should consider bumping
| to 1.x at some point and keep going :)
| dathinab wrote:
| Skip 1.0 and 2.0 to brake people's expecting.
|
| Like at some point just e.g. move from 0.69.0 to some
| arbitrary number like 7.0.0 or even 70.0.0.
| simiones wrote:
| Java did that, right? From Java 1.4 to Java 5.
|
| Also, at $WORK we have three separate but related products,
| each with separate version numbers that we jumped at some
| point to reach the same value across all 3. One of the
| products jumped from 3.x to 9.0 I believe.
| _tom_ wrote:
| Java 5 was still v1.5, except for marketing, iirc. The
| 1.x versions persisted internally for a few releases.
| dathinab wrote:
| Java moved from 1.4 to 1.5 and just stopped displaying
| the 1.
|
| The reason was that they committed to never to any "major
| braking change" i.e. that there would never be a version
| 2.
|
| At the same time the backwards compatibility guarantees
| didn't work always as good as some people liked so they
| decided to move from semver to something which is like
| "only do minor releases, but sometimes imperfect making
| them somewhat major releases but also somewhat not".
|
| What I advocated for differs in that I want to keep
| semver. So when you move from e.g. 0.32.0 to 32.0.0 you
| still would only inc minor version for non braking
| changes and the patch version for patches.
|
| Through this means that you now can denote path updates,
| as in 0.32 the minor updates are like major updates and
| the patch updates are like minor updates.
|
| This can be especially useful when development release
| speed slows down and you want to make a new release with
| e.g. just fixing some API docs or just non API exposed
| bug fixes.
| magic_quotes wrote:
| Java / OpenJDK never used semver in the first place.
| Also, large projects like Java have entire _layers_ of
| different APIs, whose compatibility guaranties can 't
| really be described with a single number, no matter what
| versioning scheme they use.
| Heliosmaster wrote:
| why not switch to a year-month then, if the release process
| is already time-based?
| emteycz wrote:
| 1. cost (and risks) of switching - not just for the project
| itself, but across the ecosystem and all the millions of
| users
|
| 2. what if you need multiple releases in a month, in a day?
|
| 3. if it works, don't touch it
| nick__m wrote:
| i dont have awnsers for 1 and 3 but reagarding 2 the
| format YYYYMMDD.NN allow you to have 100 releases a
| day...
| nicoburns wrote:
| Monthly? There were 3 releases in 2019, 2 in 2020, 2 so far
| in 2021 if you count the imminent 0.65 release.
|
| I guess maybe it's monthly if you count the patch releases?
| But you can't really claim to "just increase the number by 1
| each time" when you have two separate numbers which get
| incremented for different reasons.
| vjeux wrote:
| I haven't worked on React Native for many years now...
| looks like it has slowed down! It was monthly in the first
| few years.
| jrochkind1 wrote:
| Do you have any policies around backwards compatibility? Is
| there any way to know if a given release has intended
| backwards-breaking changes or not?
| formerly_proven wrote:
| OpenSSL went to double-letter patch versions in their 0.9.x
| days, for example 0.9.8zh.
| throw0101a wrote:
| > _OpenSSL went to double-letter patch versions in their
| 0.9.x days, for example 0.9.8zh._
|
| They only used single letters:
|
| * https://www.openssl.org/news/changelog.html
|
| The IEEE Ethernet standards are using double letters though:
|
| * https://en.wikipedia.org/wiki/IEEE_802.3
| Denvercoder9 wrote:
| _> They only used single letters:
|
| > * https://www.openssl.org/news/changelog.html_
|
| From that link:
|
| _> When a release is created, that branch is forked off,
| and its changelog is also forked. For example, none of the
| changes after 0.9.8n appear in the other logs, because
| 1.0.0 was created after that release and before 0.9.8o._
|
| If you look at the changelog in the v0.9.8 branch, you'll
| see they got up to 0.9.8zh:
|
| https://github.com/openssl/openssl/blob/OpenSSL_0_9_8-stabl
| e...
| xd1936 wrote:
| Who were you, Denvercoder9? What did you see?
| Threeve303 wrote:
| The legend of Denvercoder9 continues to this day
| k__ wrote:
| Many OSS projects were and still are pre 1.0 for years.
|
| I think, it's a sign of hybris if a project owner goes 1.0 too
| soon.
| julianlam wrote:
| ... hubris? I think that's a bit much.
|
| We went v1 once we decided our software was ready for other
| people to use. It meant we'd ensure compatibility via upgrade
| scripts, and it meant we wouldn't do irresponsible things
| like tell users "this release requires you to drop your
| database and start over"
| k__ wrote:
| I think, that's the main problem with SemVer. Everyone
| tries to merge the major version with some kind of nebulous
| "readiness". While it should just be a number related to
| technical aspects of the software.
| superjan wrote:
| And I think that is the right way to think about it. I
| think people stay on 0 because they think they have to
| implement all ideas and edgecases before it you can call it
| 1.0. You can also get stuck on 1.x releases in the same way
| (notably Java).
| mytailorisrich wrote:
| If you have a set of working, useful features, however small
| as long as they part of your core product, and you release to
| the public then you have your v1.0.
|
| IMHO, if you stay pre 1.0 for years across many releases it
| means you have too wide a scope for what v1.0 should be.
|
| Essentially, your MVP is v1.0 since that the first viable
| product you release.
|
| But what sometimes happens is that people imagine v1.0 as
| being the full vision with everything and so they never
| really reach it. And of course sometimes it seems that there
| is no sensible explanation at all for why a product is still
| pre 1.0 to the point of being ripe for satire, indeed (and
| ZeroVer is really on point the way it satirises this!).
| joshxyz wrote:
| yup sounded like a joke until the table LOL
| uncomputation wrote:
| (Just wanna make it clear that this is a joke. The footer
| says published April 1 and the about page states it is satire
| just for anyone confused.)
| nightcracker wrote:
| I don't think calling it a joke is correct. It correctly
| self-describes as satire, which is quite different. Both
| use humor but one is not meant seriously whereas the other
| has a serious critique behind it.
| tialaramex wrote:
| A good satire _should_ have a serious point it dismisses
| as part of the joke. For example Swift 's "A Modest
| Proposal" is famous for its recommendation that Ireland's
| problems will be solved if the Irish eat their children,
| but it explicitly dismisses the possibility of taxing
| "absentee landowners" and other wealthy people and _that_
| is what Swift thinks you should actually do.
|
| The closest ZeroVer comes is to quote Tom Preston-Werner,
| "If your software is being used in production, it should
| probably already be 1.0.0." which is something, but could
| perhaps be dismissed more thoroughly as undesirable or
| mistaken in this document.
| wott wrote:
| > For example Swift's "A Modest Proposal" is famous
|
| Given the context, I thought for a minute that you were
| talking about Apple's presentation of the rationale for a
| successor to Objective-C.
| capableweb wrote:
| ReactOS existed for 25.5 years, now on version 0.4.13.
|
| Tor has been around for 17.3 years, now on version 0.4.7.0
|
| Seems getting rock-solid software to >1.0 takes a rock-solid
| effort.
| ziml77 wrote:
| ReactOS makes sense to still be at version 0. Even with all
| the work put into it, it's still not usable as a daily
| driver.
| divbzero wrote:
| SemVer FAQ [1] specifically recommends starting with 0.1.0.
|
| [1]: https://semver.org/#faq
| jokoon wrote:
| using the an ISO date with a release/beta/branch-name as a
| version number always make more sense to me...
| jeltz wrote:
| For end user applications? Sure. But for libraries where API
| compatibility matters I think semver is superior.
| eurasiantiger wrote:
| Proper semantic versioning gives you certain guarantees.
|
| Consider you're on v1.2.1 of some package, pinned to your
| requirements as "^1.2.1".
|
| A security issue gets fixed, v1.2.2 is released, your CI/CD can
| manage this upgrade automatically.
|
| A new feature is introduced, v1.3.0 is released, your CI/CD can
| still manage this upgrade automatically. Developers know that
| there are new features because the minor version was
| incremented.
|
| But then, some core API refactoring is done to support new
| integrations, which happens to break backwards compatibility.
| Now, v2.0.0 is released, and it is obvious to developers that
| something major has changed. Your CI/CD does not do this
| upgrade automatically.
| kashug wrote:
| we tried semantic versioning for some time, but gave up. It
| is still people writing the code - and people do mistakes. So
| even when something is released as a patch how do we know
| that it was a mistake and it should have been a minor or a
| major version. Or they introduced a bug that would break our
| system?
|
| So in the end we would still end up not trusting it and rely
| on testing (hopefully as automatic as possible) before we
| could merge the upgrade.
|
| In the end we just switched to using timestamp-based version
| numbers and just try to upgrade often enough so each
| incremental change is small. And try to have good automatic
| tests that can do most of the regression testing for us.
| jrochkind1 wrote:
| If my CI says a patch release broke my build, I think "I
| should figure out why, and report the bug unless it's
| already reported. This is a debugging task. If I can find
| time to do it now, it would be contributing back upstream."
|
| If my CI says a major release broke my build, I think "OK,
| I will put this aside and schedule time to deal with it
| based on how important it is to upgrade, maybe I'll take a
| peak at the release notes (breaking changes section) now to
| get a sense of what might have broken and how much work it
| might be." And reporting a bug upstream is unlikely to be
| part of the work.
|
| It's important signalling that helps us all cooperate to
| produce stable software, not just our own software, but the
| open source ecosystem we (in the best case) cooperatively
| develop.
|
| It's also just about the only sane way to manage indirect
| dependencies that might be depended upon by multiple
| activated things. Widget and Doodad are both used by my
| project, and both depend on Button. How do we figure out
| what version(s) of Button will be (are intended to be, sans
| bugs) compatible with both of them?
| kortex wrote:
| Eh, I would contend that poorly done semver is still better
| than date (only) versioning. You can always have date
| and/or hash as part of the metadata string. As long as you
| are honest with your team, saying "these are a best-effort
| to follow semver" it's clear what you are doing. If you are
| sub-1.0 basically every release is a minor bump anyways.
| jeltz wrote:
| Miatakes happen but as an end user of a library I prefer
| having semantic versioning giving me a hint on where it is
| likely there is an API breakage and where there is unlikely
| to be one. I still use lock files, read release notes and
| test but knowing where things are likely to break saves me
| time.
| jrochkind1 wrote:
| Agreed.
|
| And I definitely _don 't_ read release notes of _all_ my
| dependencies, even _indirect_ ones, every time I update
| any. I lock to major versions (and hope my dependencies
| do to for indirect dependencies), and only look at
| release notes if an update breaks a build.
| wadim wrote:
| I'm also a big fan of CalVer (https://calver.org/), though I
| think it totally depends on the context. I wouldn't want to
| write C++ libraries with it.
| ThePadawan wrote:
| I find it funny that CalVer highlights Ubuntu as a good
| example.
|
| I like Ubuntu when it uses its CalVer versions, but if I have
| to look for a specific package, I still have to check which
| one Xenial is after looking at the apt sources.
| dmos62 wrote:
| > Low in the stack, low in the version. That's the HashiCorp way.
|
| > Most experts have come to agree, for all their complexity and
| absurdity, Kafka's writings have been influential, despite the
| prevalence of bugs.
|
| I'm loving this.
| khanan wrote:
| Too bad the "article" is written in 2018 and Hashicorp release
| Vault 1.0.0 December 3rd, 2018 :)
| Sebb767 wrote:
| It seems HashiCorp got the message ;)
| smsm42 wrote:
| Kafka part is brilliant, too bad they went to the dark side
| with 1.0 release in 2017.
| jl6 wrote:
| It's a joke at the expense of projects whose developers have no
| idea when their own software will be finished. You can't ever get
| to version 1 if you have no clear goal or sense of what being
| done means. The idea of requirements is now thoroughly out of
| fashion. And I suspect that a lot of projects stay hazy on their
| purpose in order to keep the door open for a pivot to the latest
| trendy concept, or an acquihire.
| dhagz wrote:
| I'm going to be pedantic and say the idea of _fixed_
| requirements is out of fashion. The software I write has
| requirements, but they change about 1 /3 of the way through
| each sprint.
| [deleted]
| dbrueck wrote:
| IMO the best versioning convention is YYYYMMDDNN, where NN is the
| release number you did that day (and so is typically 0).
|
| With this, it's trivial to generate new version numbers, there's
| no version number angst, and version numbers are inherently
| ordered. Detractors will argue that this system doesn't convey
| compatibility or magnitude-of-change information, but that's a
| feature.
| hnlmorg wrote:
| > _To drive the point home, even further down the stack,
| HashiCorp 's Terraform also complies with ZeroVer's cutting-edge
| versioning scheme. With Vault and Terraform, HashiCorp
| demonstrates industry recognition of the importance of ZeroVer in
| infrastructure._
|
| Both of these have seen 1.x releases.
| inanutshellus wrote:
| Page was made April 1st, 2018, so that's probably just bitrot.
|
| That said, I like to think they did 1.x releases specifically
| because they were hoping to get off this Wall of Shame.
| njharman wrote:
| I can't tell if this is a spoof or joke?
|
| This entire section reads like a joke post
|
| > 0verview Unlike other versioning schemes like Semantic
| Versioning and Calendar Versioning, ZeroVer (AKA 0ver) is simple:
| Your software's major version should never exceed the first and
| most important number in computing: zero.
|
| A down-to-earth demo:
|
| YES: 0.0.1, 0.1.0dev, 0.4.0, 0.4.1, 0.9.8n, 0.999999999, 0.0
|
| NO: 1.0, 1.0.0-rc1, 18.0, 2018.04.01
|
| In short, software versioning best practice is like the modern
| list/array: 0-based.
|
| We'll leave it to computer scientists to determine how expert
| coders wield the power of the "zero-point" to produce top-notch
| software. Meanwhile, open-source and industry developers agree:
| ZeroVer is software's most popular versioning scheme for good
| reason.
| lloydatkinson wrote:
| Is this a joke or a real site? How does basically putting a 0. in
| front of every version solve anything?
| keithnz wrote:
| a joke and a not so subtle prod at all these long running
| projects that are stil 0.something
| reckoner22 wrote:
| An alternative would be to introduce a ,,marketing version
| ,,number independent of the semver version.
|
| Usually there are packages with big api differences for the first
| 3 versions or so. The major version number is used to discuss
| bugs, development, etc. New versions usually entail a beta period
| that results in two active versions for a while.
|
| This would allow the major version to be used more often for
| breaking changes to help with automated dependency update tools.
| jeltz wrote:
| PoatgreSQL used to do this and they abandoned it for good
| reasons. Too much bikesheddinr about when the marketing number
| should be incremrnted and too many confused users who (with
| good reason) thought the marketing number actually meant
| something.
| gHosts wrote:
| I wish I was joking.
|
| But our versioning scheme doesn't include zero.
|
| Not even for minor version numbers.
|
| As we (rightly) believe our customers don't trust them (for good
| reasons).
| ThePadawan wrote:
| All humans are weird. If you're not used to reading version
| numbers, you'd be surprised that 1.10 comes after 1.9 and vice
| versa.
| blueflow wrote:
| Only in the US, the rest of the world also uses this format
| for dates: 1.10 is 1st october and 1.9 is first september.
| account42 wrote:
| There are plenty of countries outside the US that don't use
| '.' as a date separator.
| Joker_vD wrote:
| Even in the US format, the 10th of January is still after
| the 9th of January.
|
| Perhaps the correct sentiment would be "If you're not used
| to reading, you'd be surprised that 1.10 comes after 1.9
| and vice versa".
| ThePadawan wrote:
| I have no idea how you or your parent immediately arrived
| at calendar dates (which in my book require a period at
| the end), but to everyone i know, 1.10 is not a date, but
| a floating point number with the same magnitude as 1.1,
| which is thus closer to 0 than 1.9 is.
| blueflow wrote:
| How would October 1st be written down at your place?
| ThePadawan wrote:
| 1.10.
| blueflow wrote:
| Ah i see, the trailing dot.
| Joker_vD wrote:
| What locale is that? I know that e.g. de-DE uses trailing
| dot to mark ordinal numbers, so "1." means "the first",
| but it also uses decimal _comma_ instead of decimal
| point, so there is no confusion.
| ThePadawan wrote:
| TBH, I'm German, but a Software Engineer, so it's a mix
| of both.
|
| I don't know what an average German would make of "1.10",
| really. I've only seen that as "subsection 10 of section
| 1 of a book".
| hyperman1 wrote:
| I've always wondered if windows 3.11 was not meant as a minor
| upgrade of 3.1, but they assumed versions are a float so
| 3.1.1 was out of the question. There is AFAIK no windows 3.2
| to windows 3.10
| account42 wrote:
| There are also plenty of humans (and software) that will
| change x.y.z to x.yz
| jrochkind1 wrote:
| One reason I think adding the third component is useful. At
| least 1.10.0 is clear you aren't looking at an ordinary
| decimal point number.
| vintermann wrote:
| Bijective base 10 versioning!
| marcosdumay wrote:
| That's actually a good idea. It takes away all the stress over
| deciding if some released thing is ready (for what?, anyway,
| it's not up to you to decide), and removes the stupidity of
| "semver does not apply if it starts with a zero".
| keiferkif wrote:
| I was ready to lose it on what I perceived as more pretentious
| developer shit, then I realized it was satire thank the Ford.
| matsemann wrote:
| I always bump major even though we follow semver. I consider my
| contributions _major_ no matter how small. No impostor syndrome
| here, sir. ( /s)
| PebblesRox wrote:
| ZeroVer is versioning for perfectionists.
|
| https://news.ycombinator.com/item?id=28089287
| astrobe_ wrote:
| In some sense yes.
|
| It can mean that the authors think that they are not done with
| it.
|
| In some cases, the cause can be a insufficiently defined scope,
| and feature creep can be a consequence.
|
| In other cases, authors might have the correct intuition that
| the first impression can be very important, so going out and
| releasing Version One can cause great anxiety.
| lamontcg wrote:
| What this really does is highlight the way that SemVer is broken.
| Or at least the arguments that users and maintainers have over
| SemVer is broken.
| kzrdude wrote:
| major useful software like numpy and pandas were using 0.x
| versions for a long time. They were useful for all that time, and
| books were written, but they have now both come over to 1.x
| versions (pandas more recently than numpy).
| mrtweetyhack wrote:
| So if there is always a 0. in front, then just take it out an
| assume it's there
| bungle wrote:
| True ancestor to this:
| https://en.m.wikipedia.org/wiki/Enlightenment_(software)
|
| " The first version of Enlightenment was released by Rasterman
| (Carsten Haitzler) in 1997.[5]
|
| Version 0.17, also referred to as E17, was in development for 12
| years starting in December 2000[6] until 21 December 2012 when it
| was officially released as stable."
| jiggawatts wrote:
| That brings back some memories! Back in '98 or '99, I ran into
| Carsten at UNSW and started talking to him because I thought it
| was cool how he used roller blades to go between classes.
|
| He set up my Linux login with Enlightenment before many people
| had even heard of it. My fellow students in the same year were
| using some hideous black & white (not even greyscale!) window
| manager, meanwhile I had this awesome colourful setup that felt
| like it was from the future.
|
| Fun times...
| devy wrote:
| This blog post titled "ZeroVer: 0-based Versioning" was
| originally written on April 1, 2018, even though the "Notable
| ZeroVer Projects" section seems to be updated and current for
| this year.
|
| The canonical URL is
| https://0ver.org/zerover_0_based_versioning.html
|
| The entire site only has a single blog post.
|
| Go figure.
| hyperman1 wrote:
| WindowMaker! I remember using it at the end of the 90s, thinking:
| It is fine. Just go to 1.0 already. Yet here we are, 20 years
| later.
| kazinator wrote:
| They forgot Linux, which started at 0.x and was at 0.99plX for a
| number of patch levels X before being released as version 1.
|
| The minor numbers should always start at zero.
|
| The major number starting at zero lets us express that the
| program is not released.
|
| I.e. we are actually using 1-based versioning for the major
| number, and are reserving the 1 for the first stable release when
| the beta program is considered to have shipped.
| lugged wrote:
| I remember when you might worry about getting fired using alpha
| version code in production.
| 404mm wrote:
| It's borderline comical to read such strong opinions about how to
| version your software.
|
| "One shall not speak of 1.0!" (Not an actual quote).
|
| If 0ver works for your use case, go with it, by all means. It's
| sortable ("nat-sortable" to be more precise) and it will get the
| job done. And so are many other versioning schemes.
|
| Think about your release cadency, how will you release new
| versions, patches and fixes and then pick one that makes sense to
| both humans and your code.
| shawxe wrote:
| I'm pretty sure the page is supposed to be satirical. It's
| poking fun at the number of software projects that have been
| around for several years (or maybe even a couple of decades),
| have had dozens to hundreds of releases, and yet are somehow
| still at major version 0, which flies in the face of both
| semantic versioning and general common sense.
| 404mm wrote:
| Wow, lol. I usually pick up on satire. It's just ...it's
| 2020-ish and it looked very aligned with various edgy
| opinions.
| cookiengineer wrote:
| I know this is a joke, but...
|
| Honestly, nobody gives a damn about software version numbers
| outside the developer world.
|
| Do you think your endusers care about semantic or zero
| versioning? Probably not.
|
| I liked the Ubuntu (or previously msoffice) approach, as people
| can predict when new software is going to be released, and they
| immediately know how old an installation is.
|
| Maybe someone should propose a year / datetime based versioning
| scheme here...
| maxekman wrote:
| For backends etc I like to use year.week.build: v2021.32.1 for
| today's build.
| pbhjpbhj wrote:
| Inkscape is a notable 0ver user until a recent lapse!
|
| I'm still on 0.9... , for, y'know, religious reasons. 18 years on
| a 0ver is hard to quit!
|
| (Seriously, I'm not sure the 1.0 is in the Kubuntu repos for my
| version).
|
| https://launchpad.net/inkscape/+milestone/1.0
| ziml77 wrote:
| I hate that so many projects don't ever move to version 1. It
| makes it hard to choose to use them for anything serious because
| 0.x implies that the developers don't think the project is ready
| yet.
|
| I think the reason projects get stuck at 0.x is because of
| interface stability expectations. When you're at version 0, you
| have the freedom to realize you made a bad choice and break
| interfaces to improve it in the long run. It's nice to know you
| have that freedom and that you're not committing to maintaining
| something in a state that is painful to work with.
| another-dave wrote:
| Semver also allows you to make breaking changes at anytime with
| the bump from one major version to the next -- e.g. if you look
| at something like RxJava they use semver well in this way &
| don't shy away from breaking changes to deprecate and tidy the
| API.
|
| If anything I think perpetual v0 dilutes the concept as gets
| people used to projects being stable at v0 rather than
| considering them alpha
| KingMachiavelli wrote:
| It's satire but technically some of those projects may just be
| following SymVer [1] but have never reached the point of being
| able to claim whether an update is breaking or non-breaking.
|
| [1] https://semver.org/
| krinchan wrote:
| I realize terraform turned 1.0 recently but I still harbor a lot
| of anger towards them for 0.11 to 1.0. They were selling support
| and enterprise features and convinced everyone to go all on on
| terraform and the result was pure hell getting from minor version
| to minor version. Upgrade fatigue set in hard in my org and I
| still have teams I stumble across sitting on 0.9 and refusing to
| upgrade.
|
| The only pass terraform gets is that it was the least worst of
| IaC at the time. And even now in the day of k8s, on-cluster
| CI/CD, and AWS-account-per-team, something has to provide the
| initial k8s cluster, VPC, Client VPN, etc. before your devs can
| use an account.
| busterarm wrote:
| Uhh...I've been using Terraform at very large scale since 0.7,
| without Enterprise, and the only truly painful upgrade in this
| chain was 0.11 to 0.12.
|
| There might have been some pain in specific providers, but at
| the same time those updates were going on, all three major
| cloud providers rewrote their own APIs.
|
| Everything since 0.12 has been literal sunshine and rainbows
| flying out of our butts. The tool is _that good_ now.
| krinchan wrote:
| We have an internal provider that handles generation of IAM
| Roles and IAM users via an external API for various security
| reasons I may or may not agree with. The constant provider
| changes in 0.10 and upward were extremely painful. We
| actually ended up having several teams who so hopelessly
| fubared their tfstates trying to skip minor releases, we
| ended up having to take it away and put together a task force
| to do it ourselves across almost 200 repositories.
|
| I'm not sure what you mean by "all three major cloud
| providers rewrote their own APIs." Azure[1][2], AWS[3], and
| Google[4] are all maintained by Hashicorp. In fact, if you
| peruse the issues you'll often see PRs opened by employees of
| the respective providers trying to fix blocking issues and
| they often devolve into literal begging for Hashicorp to
| respond and at least tell them why something hasn't been
| merged. I know one blocker[5] actually cost Azure a very
| substantial customer as it languished in Hashicorp's queue.
|
| Hashicorp's constant refrain of "Well it's a 0 version
| software" while selling enterprise support and constantly
| shilling their wares as production ready across the entire
| DevOps space was dishonest.
|
| I appreciate the position they were in and I appreciate even
| more their attempt to at least put out a good PR move with
| their 1.0 release. We will see how well it holds up over the
| years.
|
| What you call "that good" I call "better than everything else
| but still byzantine and hellish to deal with every time
| someone DMs me, 'hey, you know terraform right?'"
|
| 1: https://github.com/hashicorp/terraform-provider-azuread
|
| 2: https://github.com/hashicorp/terraform-provider-azurerm
|
| 3: https://github.com/hashicorp/terraform-provider-aws
|
| 4: https://github.com/hashicorp/terraform-provider-google
|
| 5: https://github.com/hashicorp/terraform-provider-
| azurerm/pull...
| lmilcin wrote:
| I believe that after half a dozen releases 0 stops being
| meaningful and is just reflection on somebody's inability to make
| a decision.
|
| I make my point by always numbering my first prod release as
| 1.0.0.
|
| It is never going to be perfect and it is always going to be in
| state of flux.
|
| Why try to push responsibility onto client by telling them "Guys,
| we have warned you, this is still version 0"?
| Agentlien wrote:
| I enjoyed this. It was funny and had some really good jabs at
| some of these projects.
|
| I'm also happy that its list of notable ZeroVer projects includes
| Dwarf Fortress, currently at v0.47.05, 15 years after the first
| version was released.
| smcameron wrote:
| Heh, my hobby project has been at version 0.1 since 2012 I think.
| But it's ok, because I've made no releases (it only runs on
| linux, and you have to compile it yourself. I find this keeps the
| quality of users, bug reports, complaints, etc. higher and the
| numbers lower). And also, it's a silly space game, so nobody
| cares anyway. And the really important thing to version is the
| network protocol it uses, currently at 53. The "versions" of the
| software are really the git commits. I try really hard to ensure
| every commit is viable (so that git bisect works, and so the top
| of the tree always works).
| MauranKilom wrote:
| Looks like fail2ban (16.8 years of being zero-versioned according
| to this site) is actually on the path to a 1.0 release:
|
| https://github.com/fail2ban/fail2ban/commit/3f5c382a988bb21f...
|
| Well, the master branch is considered 1.0 at least. Not sure if
| there's been an official 1.0 release though...
| bacan wrote:
| Not sure if this a joke, but zerover sounds like the worst idea
| ever. Whole numbers are intuitive, easy to understand and easy to
| compare.
|
| It is way easier to compare something like 1.0 & 2.0 than it is
| to compare 0.1.9 & 0.2.0-rc.2
|
| Plus then you get the added advantage of Major/minor versions.
| jessaustin wrote:
| TFA:
|
| _...software versioning best practice is like the modern list
| /array: 0-based._
|
| elsewhere in TFA:
|
| _Welcome to ZeroVer 0.0.1._
|
| Anyone familiar with zero-based lists surely would have suggested
| "0.0.0"?
| seaish wrote:
| I'd like to think 0.0.0 is when the idea is still in your head.
| lvxferre wrote:
| Guys. I'm not even a programmer, but even I could notice right
| off the bat this is satirical, when they claimed there's some
| "consensus" about major versions being over.
|
| That said I wish developers realised more often, how meaningful
| version numbers are for the users. Zero as a major version
| screams from a distance: "we're just testing stuff out, expect
| features to be added and promptly removed because they shouldn't
| be there, this is not production-ready, use it at your own risk".
| what556 wrote:
| This is being sold as "Cutting-edge software versioning for
| minimalist" but requires you to have an additional number in your
| version that does nothing
| quickthrower2 wrote:
| It's like saying the UTF BOM does nothing. The 0. prefix tells
| you it's an enlightened project.
| [deleted]
| Errik wrote:
| I've to admit it: I read through it with increasing disbelief,
| feeling old and outdated, until I've reached the release date.
| dathinab wrote:
| The fear of not releasing 1.0 because of some strange believes
| that you can't release 2.0, 3.0 or 2364.0 or that 1.0 needs to be
| special in some way is really annoying.
|
| The moment your software is production ready it should not take
| long until you use major version numbers.
|
| If you are afraid of users expecting no change breaking after 1.0
| don't stay below it as the user also expects 1.0. instead brake
| expectations by avoiding 1.0 and 2.0 specifically. E.g. jump from
| 0.69.0 to 69.0.0 or some other arbitrary number like 42.0.
| StephenJGL wrote:
| I love the religious overtones on the post. All I can say is that
| the best option is probably to coexist.
| chaboud wrote:
| This is actually a great little advertisement for CalVer and
| SemVer baked into a send up of some pretty important projects
| with goofy ZeroVer history.
|
| I use ZeroVer on documents that are in a draft state to signal
| that they're draft, and the version drops once the doc is final.
|
| SemVer is great for protocols, as it signals compatibility
| promises, and the ZeroVer alias of a protocol version means it's
| in development (there be dragons).
|
| CalVer is great for software releases, operating systems, etc, as
| it makes debugging/triaging easier.
|
| Whichever you use, version your protocols and releases please.
| It's an incredibly common problem with software, that people
| don't think about the value of versioning and the impact it has
| on parallelism in engineering/development.
|
| Versioning. Do it.
| jrochkind1 wrote:
| 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....
| dcow wrote:
| 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.
| jgilias wrote:
| 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.
| hashkb wrote:
| 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.
| williamdclt wrote:
| 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.
| seph-reed wrote:
| > 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")
| vitro wrote:
| From the About page:
|
| > ZeroVer is satire, please do not use it.
| smsm42 wrote:
| Unfortunately, from the main page it's clear everybody does
| anyway.
| JadeNB wrote:
| > 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?
| themacguffinman wrote:
| 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.
| robertlagrant wrote:
| Here's something that's not zero: the number of comments from
| people that don't get the joke.
| tonyedgecombe wrote:
| Humour is wasted on Hacker News.
| rojoroboto wrote:
| this is my favorite comment.
| twobitshifter wrote:
| Having worked at a place with 11+ years of a project in ZeroVer,
| I would caution against ZeroVer as it can mentally wear on
| software developers. The 0. is not something embraced, but a
| taunting God who takes pleasure in suffering. The followers of
| ZeroVer all believe that with some combination of magic and hard
| work a 0. will turn to a 1., but the mighty 0. never rolls over.
| To topple the 0., they will try tricks like a full rewrite of
| core code, new scrum patterns, new directors of software
| development, more code reviews, iron clad specifications, testing
| specialists, and more. They'll try to do things they see 1.0
| software doing: sell the code, use it in production, make billion
| dollar decision based on its output, have entire livelihoods
| wrapped up in its existence, and still the 0. is unchanged. The
| myths of a roadmap to 1.0 will build over time, some say it's
| always existed, but there's no sign of a road or even
| civilization when you look around. The ZeroVer faith says that
| everyone is always on the road to 1.0 if they believe, but
| outsiders continually taunt them for not knowing when 1.0 will
| reveal itself.
| arcatek wrote:
| I know you're joking, but I worked in a startup where a massive
| effort was made to completely rebuild the 1.x website - both
| backend and frontend. It required a lot of work from everyone,
| and I remember we even stayed late more than a few times to
| bring it to finish line.
|
| So it was a bit disheartening that the founders never bumped
| the version to 2.x once the rollout was achieved. It's perhaps
| a bit nitpicky, but it felt like the work wasn't properly
| appreciated.
| debarshri wrote:
| I have seen completely opposite things in my previous startup
| I worked for. The product wasn't event production ready, they
| would call it version 1.0, version 2.0 and now version 3.0
|
| Versions were bumped now and then, without real major
| changes.
|
| They use this as marketing gimmick to create buzz that
| something major is being released but actually it was same
| old stuff just not ready for primetime.
| _puk wrote:
| Unfortunately I've found there often needs to be separate
| internal and external version numbers.
|
| An internal rewrite where all the "old bugs" are fixed, but
| minimal new features are added may feel like a 2.0 for those
| who worked on it, but for external customers it's the same
| tool, with the same functionality, just maybe looks a little
| different.
|
| A 2.0 is often heralded with marketing fanfare, so it needs
| justification.
|
| I'm not saying it's right, or that one rule fits all; I've
| seen it first hand and feel your pain.
| yjftsjthsd-h wrote:
| And on the flip side, sometimes internal version 11.3 is a
| boring release with only small changes since 11.2, but if
| one of those changes was a feature that marketing cares
| about then bumping to The New Exciting 12 may be in order.
| fomine3 wrote:
| Opposite(?) example is Windows NT 5.1 / 6.1
| koheripbal wrote:
| Maybe I'm aged, but I always just use the date. If I build
| today, the version will just be 210811.1 and it updates
| automatically in each build.
|
| I'm a one man shop though so I never branch for major/minor
| releases.
| ThinkBeat wrote:
| This is what makes sense to me as well.
|
| It is also much easier to reference when talking with other
| devs, users, etc.
|
| We all know the calendar and a date is much easier to
| remember.
|
| Straight increases 5, 6, 7 ar also easier for user to
| reference.
| kbenson wrote:
| Ask me how I can tell you haven't been using this strategy
| for more than a decade or two. ;)
|
| I say that mostly jokingly, but stuff like this was really
| annoying around the turn of the century, in a death by a
| thousand cuts kind of way.
|
| Please, just put the full year in. It's only two more
| digits, and will prevent the older people that see it from
| building a little bit of rage up every time they see it.
| codetrotter wrote:
| Y2K100, aye!
| JoBrad wrote:
| Or even trying to determine which value represents year,
| month, or day. Internet date format is the only way to
| go, IMO.
| gowld wrote:
| I've been using it for over 20 years...
| orian wrote:
| minor/major makes sense for, when a company plans to
| support a major for longer period of time, if the
| development is continuous, the date sounds good
| nwatson wrote:
| This works well only if you're supporting a linear
| evolution of releases, no branching or LTS or back-porting.
| goerz wrote:
| There's nothing that says you can't have patches in
| calver, as e.g. `YY.MM.patch`. So you can definitely have
| an LTS calver release, or even back port new features.
| You just have to do it in the patch version, or adopt
| some other variation of the scheme,
| e.g.`YYYY.minor.patch` or `YY.MM.minor.patch`
| trm42 wrote:
| I've come to the same conclusion for the main product which
| always moves forward and currently has limited and tightly
| coupled relations. If the product gets lots of external
| consumers, then making it more versioned might make sense.
|
| But for common libraries SemVer feels good solution for not
| breaking the main products and helps making developers to
| think about breaking changes etc.
| tonyhb wrote:
| This is the exact strategy we use for our rollouts too.
| 2021-08-12.01 was just released.
| dnautics wrote:
| > I'm a one man shop though so I never branch for
| major/minor releases.
|
| Honestly, for my one-man projects I use 0. to indicate
| "there is absolutely no backwards compatibility guarantees
| because I'm still fucking around" and 1. to indicate "this
| is in prod and I'm confident about it" (with attendant
| discipline on how semver major/minors are supposed to be
| used).
| failrate wrote:
| Yes, and 2 is "I probably broke your favorite API."
| still_grokking wrote:
| Probably?
| gowld wrote:
| That's regular Semantic Versioning
|
| https://semver.org/
|
| > Major version zero (0.y.z) is for initial development.
| Anything MAY change at any time. The public API SHOULD
| NOT be considered stable.
|
| > Version 1.0.0 defines the public API. The way in which
| the version number is incremented after this release is
| dependent on this public API and how it changes.
|
| > If your software is being used in production, it should
| probably already be 1.0.0.
| zamalek wrote:
| Basically, nobody wants to deal with backcompat. Having
| worked somewhere where we supported stuff more than a
| decade old, it's not entirely surprising. It's really
| hard to know what crazy stuff customers are doing with
| your stuff, and fun new things often die off during the
| pitch.
| tssva wrote:
| What are you going to do when it is August 11th 2121? Reuse
| the build number?
| [deleted]
| ruined wrote:
| not a problem. it's physically impossible for any
| software to be maintained that long.
|
| you can't prove me wrong
| tssva wrote:
| Sure I can. It will just take some time to do so.
| Jiocus wrote:
| This is a solved problem.
|
| [Y2K Programming solutions]: https://en.wikipedia.org/wik
| i/Year_2000_problem#Programming_...
| thih9 wrote:
| Instruct the AI to move the project to a versioning
| system that supports full calendar year.
| dmos62 wrote:
| Add a 1. in front. It earned it.
| ziml77 wrote:
| If the project actually does last that long, I'm sure it
| wouldn't be hard to just extended the version by 2 digits
| to include the full year.
| tssva wrote:
| Is it a Mozilla project because that is some Mozilla type
| version inflation?
| williamdclt wrote:
| You mean that you're _sure_ that nothing will be
| dependent on the format of the version string of a >100yo
| project?
|
| I'd bet everything I own against that
| [deleted]
| hzhou321 wrote:
| Yeah, after 1.x, the 2.0 is one last savior. Beyond that,
| there is no hope.
| tomc1985 wrote:
| It is so weird how many people seem to have a stake in the
| version number. Personally I'm all for date or build numbers,
| and removing version numbers entirely
| matttrotter wrote:
| Yeah zerover seems kinda Draconian like "you'll never be good
| enough!"
| Kihashi wrote:
| Worth noting that this page is satire and poking fun at many of
| the issues that you note here.
| [deleted]
| kasperni wrote:
| ZeroVer is satire [1].
|
| [1] https://0ver.org/about.html
| ycuser2 wrote:
| Thank you... I couldn't understand the reason to use it.
| mjburgess wrote:
| It's so you can tell your users that the bugs aren't going to
| be fixed yet. It'll be ready by v1.
| joshxyz wrote:
| and you can break the api anytime
| jeltz wrote:
| I would say that it is more about avoiding to promise
| anything about API stability between versions.
| inanutshellus wrote:
| ...and so it's explicit... the homepage's table of projects is
| a Wall of Shame.
| snicker7 wrote:
| A brutal admission that modern software is broken and that
| stability, predictability, and correctness is just too much to
| ask for.
| styren wrote:
| Obviously they've gotten a lot of inspiration from my favorite:
| Sentimental Versioning http://sentimentalversioning.org
| david927 wrote:
| I know it's all in jest but this bothered me:
|
| > _Franz Kafka, who lived as an author in turn-of-the-20th-
| century Austria_
|
| Kafka lived his whole life in Prague, Czech Republic.
|
| Yes, it was at the time within the borders of the Austrian-
| Hungarian Empire, but calling him Austrian is irksome.
| wott wrote:
| > Kafka lived his whole life in Prague, Czech Republic.
|
| Kafka had been dead for 70 years when Czech Republic came to
| existence. He even lived only a handful of years in
| Czechoslovakia since he died young. So saying he lived most of
| his life in Austria is more correct, than assigning him to an
| entity which didn't exist at all at the time.
| david927 wrote:
| Nope. You can say Austrian Hungarian Empire or better,
| Prague. He, and the people of the time, would not say they
| lived in Austria -- which didn't exist either. The people of
| the area spoke Czech.
|
| You can't shorten the Austrian Hungarian Empire to Austria or
| Hungary. It's both lazy and wrong.
|
| Also, the Czechs fought hard for their independence and
| achieved it during Kafka's lifetime. In the same way,
| literally no one says, "George Washington, Ben Franklin and
| Thomas Jefferson, who lived in 18th-century England..." We
| don't call them English, despite having been born in a colony
| of England, because they identified themselves as American
| and were officially recognized as that in their lifetime.
| kzrdude wrote:
| Compare to someone like George Washington. He grew up in the
| british empire, in their territory. That's the fact, yet it
| sounds wrong to call him british.
| g5095 wrote:
| Why don't we just start off with OnehundredVer, to make the point
| that version numbers are arbitrary silliness and nothing
| whatsoever to do with marketing?
| mbfg wrote:
| Our teams fully embrace ZeroVer versioning. Since we all agree
| ZeroVer versioning is superior, we have dropped the leading zero
| from our version numbers and know that is just implied to be
| there. We are all happy and rejoice!
| andrewmcwatters wrote:
| Instead of listening to authors, I evaluate for large projects
| what the actual semantic version of a piece of software is, and
| other people should do the same.
|
| If someone says they're 0.11.4 and they broke the API 115 times
| in major, non-compatible ways over the last decade, they're
| 115.x.x, period. To assume otherwise is just admiring window
| dressing.
| jabiko wrote:
| Helmfile might be a good addition to the list:
| https://github.com/roboll/helmfile/releases/
| travisgriggs wrote:
| ZeroVer is obviously satire, but doesn't it just demonstrate that
| "Semantic Versioning" works great as a theory, but struggles to
| keep up with the nuances of the real world?
|
| I have multiple sub components of our system that are effectively
| ZeroVer, not because I love zero ver at all, but because
| basically a simple linear integer would have worked, so I just
| let the patch field roll so that Debian/Apple/Elixir/whatever
| tooling stays happy.
|
| For customer facing stuff, I've moved to calendar versioning
| (2021.08.12). It's easier and no or more less effective than
| arbitrary and debatable decisions to encodify some value when
| major/minor/patch changes.
| dnautics wrote:
| I would think that ZeroVer is illustrating that Semantic
| Versioning itself is working _exactly as it should_ by exposing
| the anxieties that OSS developers and communities have.
| astrobe_ wrote:
| How could they miss 0 A.D.!
| allo37 wrote:
| I feel like this is meant to be satire, but I wonder if there's
| some truth to it: Usually updates to a "major" version come with
| an implied assumption that there won't be any breaking API
| changes.
|
| Maybe being perpetually at 0 gives you the "It's beta software,
| you need to update bro" defence against maintaining a stable API,
| and all the extra overhead that comes with it.
| a3w wrote:
| Why not release 2.x after a month, breaking the API again?
| Heck, why not next day when you find out that all APIs suck.
| allo37 wrote:
| Because you'll still have customers on version 1.x, who will
| still expect support and refuse to update for <reasons>. It's
| not that it's impossible but it imposes an additional burden
| on the development team, which affects how fast you can add
| features.
| mahkoh wrote:
| That's why our team at GigaCorp has switched to not using
| minor version numbers. In the past we had customers who
| expected continuous security updates without updates to the
| minor version due to some internal policy. All of our new
| products use 0.0.x versioning where x is incremented for
| each release. This way we can easily push out new releases
| and our customers have no reason to delay updates.
| remram wrote:
| But that's the same with 0.1 and 0.2. You will still have
| users in 0.1 who will expect support and refuse to update.
| allo37 wrote:
| Unfortunately irrationally difficult customers are a bit
| like death and taxes in that sense, but "We have a new
| version with some minor fixes that you can use" is
| generally an easier sell than "We have a new version with
| some major changes that will completely disrupt your
| workflow".
| remram wrote:
| This is true no matter what you name your versions, I
| don't know what you are saying.
| iainmerrick wrote:
| _I feel like this is meant to be satire, but I wonder if there
| 's some truth to it_
|
| Yes and yes. But isn't that kind of the point of good satire?
| UglyToad wrote:
| Yes. From my perspective one benefit of 0 major version in
| 1-person OSS projects is it gives a clear signal that "yes this
| code is available for you, but no I'm not an enterprise support
| solution, I'll do what seems useful/relevant to me when I have
| time and when it feels relevant".
|
| That doesn't mean intentionally breaking backwards
| compatibility but also this isn't my paid day job so I might do
| it and I'm not going to spend my evenings compiling release
| notes / migration guides for free.
|
| In this way it's an effective anti-big-corp shield since a lot
| of enterprises have dumb rules about using beta/alpha versions.
| I think it's a strong signal where people can't just use a beta
| or pre-release version of some code that they're a) not
| auditing their dependencies and b) probably work somewhere that
| has the money to pay for that level of service but just want
| you to do it for free.
| remram wrote:
| There won't be any breaking API change _until the next major
| version_. Nothing in semvet prevents you from having releases
| 1, 2, 3, 4 instead of 0.1, 0.2, 0.3, 0.4. At some point you can
| just drop the zero and carry on, it 's false to say that you
| can't make breaking changes after 1.0.
| kazinator wrote:
| CVS/RCS is "guilty" of 1-based versioning.
|
| The linear version history of a RCS file goes 1.1, 1.2, 1.3.
|
| If we shoot a branch off, say, 1.2, that becomes 1.2.1.1,
| 1.2.1.2, 1.2.1.3, ...
|
| Switching that dead horse to zero-based would have been a
| solution in search of a problem even in its heyday when it was
| considered viable. (BSD people, feel free to read that as
| "today").
|
| We don't do arithmetic on version numbers, or not any that
| involves higher power operations like multiplication so the
| origin of the numbering doesn't matter.
|
| The components of versions are not always numeric anyway. Is
| 1.3.A zero-based or not? Is A the zero of the alphabet or the
| one?
|
| Versions for creative works have been traditionally one based.
| The first edition of a book is edition 1. The only good thing
| about zero is for indicating an alpha or beta version not
| considered to be released/published.
| altcognito wrote:
| ElasticSearch was pretty solid when it was under zerover
| [deleted]
| toabi wrote:
| But hey... even terraform made it to v1.0.0 after some time...
| https://github.com/hashicorp/terraform/releases/tag/v1.0.0
| andsens wrote:
| ... and they geared up for it by releasing two breaking
| versions in the year leading up to v1.0.0. I managed to catch
| the entire upgrade path from 0.11 to 0.12 to 0.13 to 0.15. Good
| times.
| bavell wrote:
| It was so fun reinstalling old terraform versions so I could
| unfuck my cluster infra... not to mention the joy of finding
| they removed the .13->.14 migration command in .14 so you
| have to roll alllll the way back... Good times indeed.
| WaitWaitWha wrote:
| 0. versioning sits on the throne of lies. The major and minor
| versioning continues within 0ver, just prepended with 0.
|
| As @twobitshifter (facetiously?) & @arcatek wrote, it messes
| negatively with the minds of developers.
|
| And, for decades we have been training non-technologists 0. is
| not production, 1. is better than 0., and 2. is better than 1.
| quickthrower2 wrote:
| The best versioning is the one you already have and use every
| day.
|
| It is right under your nose. You probably typed or pasted one or
| these special version strings in today or you will later. Or you
| sent one to a colleague in a slack message this week most
| certainly.
|
| It is of course the git commit hash!
|
| Suck all meaning out of your version by using the commit hash.
| Never worry about which digit to increment (semver, 0ver) or what
| date it is (calver) because who remembers the date.
|
| Also has the advantage that it's easy to check out the source
| code for a version!
|
| Use git log and pipe that to a file in /var/www and you have
| release notes with the version numbers!
| chrismorgan wrote:
| Some useful commands for making this more friendly:
|
| Get the number of commits with `git rev-list --count HEAD`.
|
| Get a label that uses the most recent tag plus the number of
| commits since and the current commit hash with `git describe`
| (read its documentation, it's got a few nice knobs to match
| whether you use unannotated tags, annotated tags, branches, _&
| c._).
|
| This sort of thing is used in Arch Linux packages based on Git
| repositories, things like this: pkgver () {
| cd the-git-repository git describe --long 2>/dev/null |
| sed 's/\([^-]*-g\)/r\1/;s/-/./g' || \ printf
| "r%s.g%s" "$(git rev-list --count HEAD)" "$(git rev-parse
| --short HEAD)" }
|
| ... which will give you versions like "1.2.3.r45.gdeadbeef" for
| commit deadbeef which is 45 commits past the one tagged 1.2.3,
| or "1.2.3.r0.g01234567" for commit 01234567 which is tagged
| 1.2.3, or "r1234.gdeadbeef" where you have no tags and 1234
| commits from the root(s) until HEAD which is at commit
| deadbeef.
| jpxw wrote:
| Perhaps this is a joke I'm not getting in which case I
| apologise.
|
| The advantage of semantic versioning (SemVer) over git hashes
| is... well... semantics. You can immediately identify if the
| next version introduces a breaking change, for instance. This
| without mentioning ordering, and being easily able to tell
| versions apart - e.g: which (if any) versions are different in
| these three versions?
|
| c26cf8af138955c5c67cfea96f9532680b963628,
| c26cf8af130955c5c67cfea96f9532680b963628,
| c26cf8af130955c5c67cfe9a6f9532680b963628
|
| You can get easy check-outs and git-logs by using git tags for
| each version.
| BiteCode_dev wrote:
| Really handy to communicate verbaly or promote.
| wraptile wrote:
| You just keep appending spaces until commit hash sounds
| human! Check out latest release: h0rs35l0v3b4tt3ry4cid5!
|
| Eventually people will start random commits like "random
| commit to change hash" when commits accidently result in
| racist or taboo terms lol
| ricardobeat wrote:
| And have no idea how recent the version is unless you have
| immediate access to git. It's a very engineer-centric idea.
| choeger wrote:
| If that's not sarcasm, and I am really not sure whether it is,
| just one counter argument: commit hashs are not ordered and
| they _can_ change.
| account42 wrote:
| > they can change
|
| This is incorrect. You can create a new commit with a
| different hash, but the commit hash being a checksum of the
| commit contents will never change for the same commit.
| Sebb767 wrote:
| > the commit hash being a checksum of the commit contents
| will never change for the same commit
|
| It will if the parent changes, for example on a rebase.
| Now, it is up to discussion on whether that is a different
| commit (technically the parent hash _is_ part of the
| commit), but most people probably consider the content
| changes to be the actual commit.
| account42 wrote:
| Then most people are wrong. We already have a word for
| the content changes: a patch. A commit is a patch applied
| on a previous state. (Or for git, a snapshot with zero or
| more previous states if you want to be pedantic.)
| Sebb767 wrote:
| If you google _what is a git commit_ , almost nobody
| points this specialty out. This is also most likely what
| the above comment got wrong.
|
| So I don't disagree with you; if we're being pedantic,
| the commit hash never changes for the same commit [0]. I
| just pointed out that what someone without an in-depth
| knowledge of git would intuitively consider to be a
| commit can indeed have changing hashes.
|
| [0] There does not seem to be an authoritative definition
| for the git-type of commit, so I guess we need to go with
| "a commit is what git considers a commit".
| [deleted]
| smsm42 wrote:
| Versioning scheme without an ordering is usually pretty bad
| idea. Also, try telling your colleague which version she needs
| to install... Might as well give up on communicating by
| anything but Slack.
| izzytcp wrote:
| No no, you have a point, gotta agree. I have my own project and
| I always know which is my latest version, it is:
| a11bef06a3f659402fe7563abf99ad00de2209e6
|
| edit 1: (sorry wrong one)
| 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
|
| edit 2: (ahh, sorry again, this is my latest version)
| a11bef06a3f659402fe7563abf99ad00de2209e6
|
| edit 3: (this is the one, definitely)
| ca82a6dff817ec66f44342007202690a93763949
| jraph wrote:
| Too complicated, just generate a UUID.
| GerryLefaux wrote:
| I find git commit hash too long for no good reason.
|
| I prefer to version with the file size, which is strictly
| increasing if you follow those best practices:
|
| - never delete any of your valuable code (commenting out is OK)
|
| - never break up code into several files (makes it simpler to
| read).
| da_big_ghey wrote:
| I hope you are making a joke, if not, you will be overjoyed
| when you find a source control system and can tidy your
| source file.
| ModernMech wrote:
| > - never delete any of your valuable code (commenting out is
| OK)
|
| So how does this work if you want to change a line in a
| function? Do you just comment out the line and write a new
| version below it? i.e. if I want to fix a bug in my code, I
| can't just fix it, I have to add a line of code to my
| program.
|
| How does this system work in practice? The way I code, it
| seems like this would lead to a huge file that is mostly
| commented.
| maple3142 wrote:
| I think it is meant to be a joke like ZeroVer.
| Scarblac wrote:
| You change the line, and add a comment explaining what the
| code used to do?
| quickthrower2 wrote:
| This, or add another cat photo to assets
| lucideer wrote:
| > _Never worry about which digit to increment (denver, 0ver)_
|
| Yay, every version is a patch and who cares if there's breaking
| changes.
|
| So now I need full QA before I pull in every security patch: a
| lovely idea in theory but in practice it's just a major
| motivator for engineers to leave their dependency tree to grow
| horribly out of date and littered with known vulns.
|
| > _... or what date it is (calver) because who remembers the
| date._
|
| Have to agree with this though, calver is pointless.
|
| All it does is caters to the general bias people have toward
| "new is better" and "well maintained = frequently added new
| features", neither of which are true.
| rubyist5eva wrote:
| > who cares if there's breaking changes.
|
| Semantic version is mostly bullshit anyway. You can never
| guarantee that a non-breaking change is non-breaking for
| every single one of your users. Anecdote: Just yesterday our
| entire CI process was taken down due to a bump in the AWS
| ebcli package from 3.20.0 -> 3.20.1. This should have been a
| non-breaking change, but instead resulted in an entire days
| worth of release management being grinded to a halt.
|
| Pin your versions. Test all upgrades.
| lucideer wrote:
| An anecdote about one time the system failed (yes we're
| human, nothing is ever applied perfectly), followed by the
| very simple suggestion that we instead all comprehensively
| and completely test every patch release of every dependency
| in our chain (we'd all like to but see above about humans
| and perfection).
|
| Semver brings net benefit for the times when it is applied
| correctly. For the rest, we do our best to test as much as
| we can.
| rubyist5eva wrote:
| The advice is to not just willy-nilly just pull in the
| latest patch releases just because it's "supposed" to
| work. Regularly testing and updgrading at _least_ your
| core dependencies should be part of the day job of any
| competent team. If you have too many dependencies to have
| capacity to do this on an ongoing basis - maybe you just
| have too many dependencies. Excuses don't make the
| problem go away.
|
| Just assuming you can upgrade something from 3.20.1 over
| 3.20.0 because it just happened to release 9 hours ago is
| a recipe for disaster. Pin your version to 3.20.0 -
| regularly review your dependencies, upgrade and test -
| THEN roll it out system wide. Don't just assume something
| is going to work and roll it out to everyone without
| checking because some arbitrary versioning scheme says it
| should.
|
| Be thoughtful. Methodical. Consistent.
| tikkabhuna wrote:
| > Have to agree with this though, calver is pointless.
|
| I've found calver useful for applications. It makes it clear
| how old the version you're running is. IntelliJ and Windows
| both use it and I prefer it to a version number you have to
| look up.
| lucideer wrote:
| Yes actually, you're right. Arguments for semver aren't
| really applicable to user-facing stuff as upgrades there
| are tested by release teams and generally in most cases you
| want users to upgrade always.
|
| The utopian ideal for apps in cases where someone might
| choose to use an older version (presuming LTS) would be
| somehow naming the release based on features, but that's
| not practical so date-based versioning is a really good
| proxy here.
|
| Calver's uselessness only really applies to software
| dependencies.
| simias wrote:
| That's missing the point of release versions. Git commits are
| not obviously ordered (you need access to the repo to do this),
| they don't tell you if it's a small patch release or a huge
| change.
|
| Contrast: v0.4, v1.0, v1.0.1, v.1.5 versus a bunch of SHA-1.
___________________________________________________________________
(page generated 2021-08-12 23:02 UTC)