ZeroVer: 0-Based Versioning
102 points by dmitryminkovsky 2 years ago | 88 comments- vbezhenar 2 years agoPeople just love LTS and backwards compatibility too much. I'm one of them. But it slows the industry, when you can't do API refactors and have to keep bad decisions forever.
I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often. Like new major version every year, deprecate API on the next major version, remove deprecated API on the following major version. So you have 1 year to rewrite your app if necessary.
And supporting old versions for those enterprises who would rather pay than upgrade might be a good source of income.
- dools 2 years ago> So you have 1 year to rewrite your app if necessary
Multiply this by the thousands of dependencies modern apps have and the only thing you will ever do is rewrites.
- foota 2 years agoMost applications (even large ones) do not have thousands of direct dependencies.
- foota 2 years ago
- zajio1am 2 years ago> People just love LTS and backwards compatibility too much. I'm one of them. But it slows the industry, when you can't do API refactors and have to keep bad decisions forever.
Hard disagree. API churn is (one of) the real cost of using libraries / external dependencies, so people would just rather reimplement them themselves or copy the library code directly into their project.
- lifthrasiir 2 years ago> I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often.
I indeed did this years ago---I'm the original author of Chrono [1]---and it wasn't well received [2] [3] [4]. To be fair, I knew it was a clear violation of semantic versioning but I didn't see any point of strictly obeying that until we've reached 1.0 so I went ahead. People complained a lot and I had to yank the release in question. By then I realized many enough people religiously expect semantic versioning (for good reasons though) and it's wiser to avoid useless conflict.
[1] https://github.com/chronotope/chrono
[2] https://github.com/chronotope/chrono/issues/146#issuecomment...
[3] https://github.com/chronotope/chrono/issues/156
[4] https://github.com/chronotope/chrono/blob/main/CHANGELOG.md#...
- chronogram 2 years agoI understand from the author perspective that everything below 1.0 is subject to change, from the hobby user perspective I see 0.3 to 0.3.1 and think "oh bug fix, that means I won't read it" without expecting semver.
- lifthrasiir 2 years agoAll those things happened when the Rust crate ecosystem was still much in flux (back in 2017), and I had some good reasons:
- Serde had made a very slight but breaking change in 1.0, and at that time I think it was impossible to support both Serde 0.9 and 1.0 in a single crate without a hacky workaround (which I only learned much later). So if I had to pick only one version to support, it ought to be 1.0 as the change was trivial to resolve.
- Cargo's use of semantic versioning is, while documented, not strictly conforming because 0.x.y is considered compatible with 0.x.z where x > 0 and y < z [1].
- People complained a lot when Chrono went 0.2.x to 0.3.0 as well. This is IMO the biggest reason to issue a breaking change; if people would complain in either way, I wanted to make a choice that benefits the whole Rust ecosystem more.
If this happen today I would agree that I shouldn't have done that, but I think it was not that clear cut at that time.
- lifthrasiir 2 years ago
- chronogram 2 years ago
- 26fingies 2 years agoOTOH you, as a library supplier, may be somewhat hamstrung to improve things you think ought to be improved but consider the productivity hit to your downstream consumers if you constantly break things for them. Stepping back to consider all parties, for even moderately popular projects the balance is obviously tipped in the favor of the consumers.
There are libraries out there (such as FFMpeg iirc) that will do a yearly major version with breaking changes. This is a good approach imo. FFmpeg consumers know what to expect and when to expect it.
- kerkeslager 2 years ago> But it slows the industry, when you can't do API refactors and have to keep bad decisions forever.
It slows the industry when you're spending all your time rewriting code that already works.
The question is, who is slowed down: API creators or API users? If you make regular breaking changes to APIs, it's API users who get slowed down, if you don't it's API creators who get slowed down.
Given the entire point of things that have APIs (libraries, frameworks, centralized services, etc.) is that there are many users and few creators, it's pretty clear which slows down more people.
Additionally, with good API design, you can often maintain namespaced APIs in tandem with very little additional cost. I've got a /v1/blah API and a /v2/blah API on one of my clients' websites--the v1 directory hasn't been touched in 7 years, because all the bugs anyone cares about have been fixed. It still has users (at least officially, I haven't looked at the reporting to see how often they're actually hitting those APIs). The users simply don't care about the new features in the new API, and it's not our place to force them to care.
You can do similar things with libraries (think sqlite vs. sqlite3) but this is obviously harder with frameworks (which is one of the reasons to not like frameworks). It doesn't work everywhere but it works often.
- bbarnett 2 years agoIt takes 3 years minimum, often 5, for non LTS Debian, to cycle through a library revision.
IMO, if you think distros are a thing of the past, or 3 years support of the biggest base distro is slowing things down, you're living in a bubble.
I know you prepended this with a statement saying you love LTS too, but to many, LTS is a decade or more.
And really, I have no interest running 'new shiny'. That is the absolute opposite of stable. That is where horrible, life altering mistakes live. If you want to increase your workload 100x, run bleeding edge.
And bleeding edge is anything that has any code change, outside of bug fixes and security fixes.
I know my position is not popular, but that doesn't make it wrong.
- blueflow 2 years agoLike software that requires some time to master. I can't recount all the times when i invested much time into doing it properly, only to have it all become useless and invalidated because upstream decided to throw it all away.
With you having an attitude like you do, why should i even bother with reading your documentation? Give it 2 years and it will all be obsolete. Waste of time.
Fuck innovation. I want tools that exist long enough that i can master them.
- alpaca128 2 years ago> But it slows the industry, when you can't do API refactors and have to keep bad decisions forever.
That's not true. You can simply put any breaking changes into separate namespaces. Now you have limitless backwards compatibility and yet users can selectively upgrade whenever they want the new features.
Maintain a non-trivial node project for a while and you will see why some people like stability.
- zajio1am 2 years agoLibraries are not really a problem, as you can have multiple major versions alongside, so i can have gtk2, gtk3 and gtk4 alongside, each offering its API for applications that use it, while actively developed code (in library) does not need to handle deprecated API.
Bigger problems are demons with API, where it is usually not possible to run multiple versions alongside (as they would compete on the same resources or data), so one code have to offer multiple API versions internally.
- raincole 2 years ago> I think library authors should be more relentless and break compatibility every few years.
...isn't it just how most LTSs work? LTS is long-term support, not life-time support.
- withinboredom 2 years agoI don't think you should be afraid of removing backwards compatibility. Look at WordPress that has maintained backwards compatibility for too long. It will happily run plugins that were abandoned ten years ago.
When you break compatibility, you force out abandoned crap. I agree you don't want to do it too often; but not doing it at all is (IMHO) worse.
- dools 2 years ago
- quickthrower2 2 years agoWhile this is probably satire, I sort of agree with it!
I always thought you just need two numbers, a.b
You increment b when you change something in a backwards compatible way.
You increment a when you make a breaking change.
If you are used to semver, it is like ditching the minor version and calling it a patch.
a.b is if course isomorphic to the 0.a.b system mentioned here.
The disadvantage is downgrading patch-only in semver may now be breaking change in twover but that is a rare edge case IMO.
- zajio1am 2 years ago> You increment b when you change something in a backwards compatible way.
Problem is that 'backwards compatible' is not a black-and-white criterion. Most non-trivial development could lead to changes in behavior (or at least in performance) that, while not part of API contract, could still be relevant for users.
For that reason, it makes sense to have a.b.c scheme, where 'b' is for regular backwards-compatible development, while 'c' is for targeted bugfix releases, which are hopefully devoid of such behavioral changes.
- quickthrower2 2 years agoI think you have changed my mind, thanks!
- quickthrower2 2 years ago
- conradludgate 2 years agoIt depends on the library. I personally like the minor vs patch distinction. If I see a patch version I might update immediately because I don't want a known bug in my application, but if I see a new minor feature version I might wait a bit
- diarrhea 2 years agoSame, but note a minor version encompasses all patches since the last release as well. You could have a single feature and countless bug fixes, but it will only show up as a meagre minor bump, with a suspicious zero in the patch field.
- kzrdude 2 years agoIn theory the patch verison should be painless and always a given upgrade. The minor version might have at least the same number of important bug fixes, it's just coming with a different cost of having larger changes as well.
Some fixes only come with larger changes. Like the recently posted rust regex 1.9 release. Only a rewrite of the library fixed some long-standing issues.
- diarrhea 2 years ago
- zajio1am 2 years ago
- gybon 2 years agoI prefer negative versioning for prerelease software. It's like a countdown to when your project will be viable and ready to show to the world.
Currently on version -2.-0.-61 of my social media network for dogs. It's getting there!
- return_to_monke 2 years agohow do you know when it'llbe finished, before the fact?
- dontlaugh 2 years agoThat’s not entirely unlike LaTeX versions approaching pi.
- return_to_monke 2 years ago
- megapatch 2 years agoMaybe it is time to consider INvers, irrational number versioning, as used in eg TeX https://en.m.wikipedia.org/wiki/TeX
In TeX the version approaches Pi, every new version adds a decimal. Elegant, will hold forever!
TeX 3.141592653 is 45 years old. Its companion Metafont has version number 2.71828182, you can see where this is going.
- xigoi 2 years agoDonald Knuth intentionally chose this versioning scheme to point out how much he trusts his software to never change.
- xigoi 2 years ago
- lamontcg 2 years agoSomehow we need a less horrible SemVer or a less horrible social contract around SemVer.
- seanhunter 2 years agoOr just use ISO8601-formatted dates as versions and derive huge benefits.
1. version numbers sort numerically and lexicographically in a sensible way, including across projects and packages which use the same format
2. users get educated that these preciously-held ideas they have about software version numbers are complete superstition. Like "something with a zero major number means not production ready", "something with a zero minor number means I should wait until there's a patch", "something with a major number increase means backwards-incompatible", "something with a minor number increase means backwards-compatible"
3. You know when a particular version (of everything) came out. "We started seeing a wierd bug on X date" no longer is impossible to figure out.
- tom_ 2 years agoI've done this for personal projects for years, for exactly the reasons you state - other than user re-education, my projects don't have enough users to make an impact. For GitHub releases, I get the CI script to do ``git log -1 --format=%cd-%h --date=format:%Y%m%d-%H%M%S'' (producing output along the lines of "20230708-150500-1234567") and use that as the suffix. (Add a -prerelease suffix on if it's coming from a non-default branch.) This sorts nicely and saves me 2 minutes if I need to find the commit in the history.
(These are self-contained projects. I suppose semver does make some sense for libraries that you link with.)
Professionally, it's been 99% Perforce for about 15 years, so it's routine to use the submitted changelist number, submitted changelists being numbered in the order they were subsequently committed. Sadly not fixed-width, but at least Explorer sorts them sensibly.
Two difficulties I have had doing this with git:
- there doesn't seem to be a way to get git to enforce UTC, so the dates are in my local time zone (for my projects this is not really an issue, and my timezone is almost UTC anyway)
- the CI system runs separate builds for different targets, and using the git commit timestamp ensures all builds get the same time stamp. But it's then possible to end up with timestamps significantly different from the actual release time, or (worse) out of order. I could probably do something better about this than my current "solution" of doing nothing, but this has only happened a couple of times
- zajio1am 2 years agoThat only works for software with simple linear versioning. If i have two major versions (say 2 and 3), i could still release a minor version to the older major version (so i would release 2.8, then 3.0, then 2.9, then 3.1).
- xigoi 2 years agoWhen working with versioning software that requires a version in the format A.B.C, I like to use YYYY.MMDD.N, where N is the number of versions already released on that day.
- tom_ 2 years ago
- Pxtl 2 years agoMy rules for 4-number semver:
1) major public API change. If you don't have a public API, this should never be anything but 1 and can be hidden from the user. End users don't want these they scare them.
2) minor: any planned release that doesn't break API. End users love these and plan around them.
3) revision: unplanned emergency hotfixes. Naming this way means the "next minor" we were talking about with all stakeholders is still the next minor. It also means our version numbers look like our git dag, since this one would be a branch from the last tag instead of main.
4) release: sometimes something goes wrong during the release itself. The first 3 numbers are public, this is internal-only and only appears in git tags and internal deployment notes. This way every push to prod has a unique version number, but all our change management documents are still accurate even if we had to push 2 or 3 times for a single release.
Why? First digit is about compatibility. All the other digits are about planning.
"We're working towards 1.3"
"we think this feature will be in 1.4".
"We had to release 1.2.1 because of an emergency somebody put Arabic text in their profile picture filename and that brought down the site."
"Turns out that trick with the release pipeline didn't work in prod so we had to make 1.2.1.1 while deploying".
- lamontcg 2 years agoThat at least fixes the qualitative nonsense between minor and patch updates.
I think there needs to be better project definitions around what constitutes a major change.
Projects need to be able to define things like dropping support for old versions of the underlying language in minor versions. So that the last version of support that some people might get is "3.2" and "3.3" may not install at all for them. That means that technically they are in a state where they need to do work to upgrade and are "broken" in a sense, but the actual public API of the software has not changed between "3.2" and "3.3". Supported O/S distro versions should also be able to be abandoned in minor releases. Toolchain updates can also happen in minor releases. Pulling in major versions of dependencies which are technically breaking for anyone who hits a diamond dependency issue, but which produce no major breaking API changes should be able to happen in minor versions.
That means that the contract isn't "I can pull in minor versions and you can never force me to do work" but more strictly that the public API the software exposes won't update.
There's also the problem with semver pinning that projects do where they put hard floor and ceiling pins on all their dependencies, even though their software may be fine with a 5-year old version of the dep (they've just never tested) and it may work fine with the next major release of the dep without any changes at all. Ideally for that last problem, the compatibility matrix fed into the dependency solver should really be a bit more malleable, so that the engineer can realize that the next version of dependency breaks everything and they can retconn the compatibility of their software to pin to the last working version of that dependency. This breaks the perfect immutability of literally everything about a software release, but allows for not being able to predict the future.
- lamontcg 2 years ago
- pictur 2 years agoWhat are the horrible things about SemVer? Can you give details?
- lifthrasiir 2 years agoSemantic Versioning requires you to declare a public API, which is not even remotely possible for many projects. If the public API surface is clear semantic versioning does indeed work well, but otherwise it doesn't give much information as users have no idea what the public API would be. Calendar versioning [1] or even a single-number version is more preferred in such situations.
- hnlmorg 2 years agoYes! Thank you. Exactly this :)
Nearly every org I’ve worked in has used semver internally and nearly every time their version numbers were just incremented arbitrarily because there wasn’t an exposed API.
This lead to countless problems, not least of all because semver usually requires one to manually set the version number based on the change log and people are generally pretty bad at changing point releases.
So I’ve usually ended up changing the versioning scheme to build number (generated by the CI/CD tooling) plus some extra information like git hash and/or timestamp - depending on the application and whether that build information can be easily encoded as additional metadata or not.
- hnlmorg 2 years ago
- pravus 2 years agoPeople take it too seriously and don't realize that you can't realistically categorize every single change neatly into 3 separate breakage categories. Arguments abound about how to manage this properly with all sorts of schemes. The fact that "0" is a special case that deserves any consideration is an example of it being broken, imo. What does it actually matter what the first digit is?
Version numbers just denote a change happened and you want them to roughly resemble some sort of chronological ordering. Everything else is gasoline for flame wars and company policies.
- lifthrasiir 2 years ago
- zokier 2 years agoTo me semver makes only sense if critical bug(/security) fixes will get backported to old major version(s). Otherwise downstream consumers do not really have true choices to make based on the info deduced from semver. Basically if as an upstream your intent is not to support old versions then that heavily implies that everyone should update to latest asap regardless of the brekage.
- Uvix 2 years agoEven if I always take the latest for direct dependencies, semver is still helpful preventing breakage from incompatible upgrades to indirect dependencies. If I depend on library A, and library A depends on library B, I can't fix any breakage from an incompatible update to library B. I need to wait for library A to update.
- Uvix 2 years ago
- seanhunter 2 years ago
- thatxliner 2 years agoI can’t tell if this is serious or satire. There’s no spec.
- pseufaux 2 years agoSatire, for sure. Check the about page. That said with the number of projects on this list, it might as well be serious.
- r4indeer 2 years agoIt's satire. If you're unsure, have a look at their about page [1]. They are criticising the idea of staying on a 0.x release for years even though your project is long used in production by now.
- netmare 2 years agoIt's obviously satirical. If so, the author is brilliant. Otherwise, well...
I mean just look at the project show cases. Included are the usual colossal cluster^Wframeworks that power our decaying software infrastructure.
Personally, I don't trust anything that either stays perpetually under v1.0 or exceeds v10-15.
- joseluis 2 years ago> exceeds v10-15
What do you think about internet browsers like Firefox and Chromium?
- netmare 2 years agoI find it ridiculous that Chrome, Edge and Firefox are all currently around v115. It's just a marketing term now. I've seen Firefox and Thunderbird major version numbers change for simple bugfixes. A release date would be enough.
- netmare 2 years ago
- 2 years ago
- jrockway 2 years agoThere's no point in calling it 1.0 unless you want to break compatibility with 0.x. Sometimes you get the design right on day 1, I guess.
- Conscat 2 years agoIn SemVer, you can break compatibility with 0.x within 0.x. 1.x is the promise that there won't be any future compatibility breaks within the 1.x series.
- Conscat 2 years ago
- joseluis 2 years ago
- auggierose 2 years agoIt should be satire, but it is serious. The spec is SemVer, but only versions starting with a zero are allowed. This just shows that SemVer is bullshit.
- r4indeer 2 years agoIt is satire. They want you to do SemVer (or CalVer, etc.) properly. There are arguments against SemVer, but I don't see how this one of them.
- auggierose 2 years agoThere is no proper use of SemVer. That's why people do lip service to it, but stay with the zero.
- avgcorrection 2 years agoThe 0ver projects follow SemVer.
- auggierose 2 years ago
- r4indeer 2 years ago
- pwdisswordfishc 2 years agoSatire can be serious.
https://tvtropes.org/pmwiki/pmwiki.php/Main/SatireParodyPast...
- pseufaux 2 years ago
- schmichael 2 years agoThe purpose of versioning is to communicate something to your users. (It's also necessary to increase over time for package managers to work, but that's an easy bar to reach.) SemVer tries to explicitly define exactly what's being communicated: API compatibility. I think that's great, especially for libraries, but it's neither the whole story nor what's most meaningful for most projects.
The most obvious and nefarious example is that the most severe and painful kinds of backward incompatibilities are superficially permissible under SemVer: behavior changes. To confuse the issue even more these behavior changes might be to fix a bug and restore the original or intended behavior of a feature! There's no single best way to communicate that to users through a version number: if libfoo v1.4.3 broke a behavior from 1.4.{0,1,2}, should the fix be in v1.4.4 or v1.5 because technically you're creating a backward incompatibility! Does the answer change if the buggy behavior has been around multiple patch releases or multiple minor releases? Does the scale of the behavior difference impact the versioning scheme chosen? Does the approximate number of users impacted impact the versioning scheme chosen? Probably!
ZeroVer is, in my opinion, a hacky but fine solution to this: no guarantees! The developers just want to develop and it's up to the consumers of the project to figure out what release they want to use. ZeroVer is when a project chooses not to try to communicate very much through version numbers. I think that's often better than some strict adherence to SemVer that falls apart under any sort of reasonable scrutiny.
I like how browsers have gone: basically give up on the traditional Major Version Number. A Chrome 2 or Firefox 2 that is a radical redesign would probably be an entirely new product with new branding and versions. So just bump the first number a lot to communicate feature releases to users, and bump the other numbers for basically internal build reasons. The minor, patch, and build numbers are free to be used and abused for a lot of complex purposes incredibly complex and popular projects like browsers (and operating systems) have.
I think a lot of projects, Nomad included, would probably be best represented by BrowserVer. Nomad is deeply committed to incremental improvements and backward compatibility, so any "Nomad 2.0" efforts are more likely to happen under a new project. Frankly Nomad 1.0 was more about marketing than any sort of meaningful feature or compatibility promise: we wanted to communicate Nomad was stable and reliable. Going from 0.x -> 1.x is an easy way to communicate that even if nothing more significant happened from 0.12 -> 1.0 than had happened from any 0.X -> 0.Y.
- lamontcg 2 years agoI think there needs to be a much tighter definition of what the API is and not just the entire surface area.
So if a project does a major update of one of its deps, without changing its own API, or deprecates support for an old language version or distro, it should be able to ship those in a minor version.
That means that consumers who aren't keeping up with the times may be cut off in a minor update and have to do work to consume the next update. There needs to be less of an expectation that "it isn't a major update, so I won't have to lift a fucking finger and its your fault if I need to" which is what SemVer has socially turned into.
- lamontcg 2 years ago
- avgcorrection 2 years agoThis is a funny lampooning of SemVer. That’s at least how I choose to interpret it.
- jonnycomputer 2 years agoI'm actually interested in practical examples of alternatives to Name+SemVer for
(1) data analysis oriented code (2) code to run experiments (e.g. psych paradigms)
I often find that in such code, forking is rather more common. That is, the code bases become wider rather than deeper. For example, we might run several experiments that have a strong resemblance to each other, but have any number of (experimentally relevant) tweaks. Within each fork, I rename, and restart the semantic versioning.
- Tempest1981 2 years agoDiscussion in 2021:
- malkia 2 years agobest versioning is svn/p4/g4 monotonically increasing changelist/revision number
- mhitza 2 years agoPage should be updated, Terraform nowadays is in the 1.x version timeline.
- Culonavirus 2 years agoAh yes, an ideal versioning scheme for modern video game projects!
- zetalyrae 2 years agoI noticed this the other day while writing a small server in Python. FastAPI is 0.100, fine. But I was surprised to find:
- Uvicorn is 0.22
- httpx is 0.24
- starlette is 0.28
And so on and on. More generally, the quality of Python's tooling and ecosystem is astonishingly low compared to the investment that every day pours into it.
- seanhunter 2 years agoHow on earth do people get from "the version number starts with a zero" to "the quality is astonishingly low"? It blows my mind.
Edit to add: If I was an opensource package maintainer again, my first action would be to massively bump the major version number of my packages. HUGE increase in quality right there.
- jowea 2 years agoNot the actual quality but I suspect the perception of quality by some people would genuinely be increased by bumping the version numbers. Maybe it would help with adoption.
- xigoi 2 years agoIn SemVer, having the first number be zero means that the project is still in unstable development.
- zetalyrae 2 years ago[flagged]
- jowea 2 years ago
- jowea 2 years agoAre those libraries actually not production ready as might be implied by the 0.x or are they just not willing to bump to 1.x for whatever reason? A lot of the projections mentioned in the submission seem to be production ready despite the version number.
- zetalyrae 2 years ago"Production-ready" is a state of mind.
They are widely used in production. Maybe some of them are de-facto production ready. But the developers don't want to make commitments to API stability.
And Python being Python it is very hard to statically enforce that you're upholding SemVer promises.
- seanhunter 2 years agoOnly you can decide whether something is production-ready for you. The library author doesn't know what you're trying to do so they can't possibly know whether their library is ready to be used in your production. You could be making an experiment that's going to form part of a payload for a rocket, an embedded device that gets surgically-implanted into people, is life-critical and very hard to update or you could be making an online meme generator. Production-ready really does mean completely different things in these cases.
- zetalyrae 2 years ago
- nine_k 2 years agoAstonishingly low compared to what? And in what aspects? (Asking unironically.)
- zetalyrae 2 years agoI use Rust professionally and even though it is a newer language with infinitely fewer developers and sponsoring organizations, the tooling and ecosystem is already superior. `cargo` is superior (in DX terms) to whatever nightmare is current in the Python world, `rust-analyzer` is better than to PyCharm, the ecosystem is smaller but more reliable.
- r4indeer 2 years agoI regularly hear that the tooling of Python is bad, but we've had Poetry for a while now and it just works.
Unfortunately, I'm not experienced in Rust so I cannot really compare it to cargo. However, Poetry does everything I would expect from dependency management and packaging/publishing and I've never had problems with it.
Also, there is ruff [2] (ironically written in Rust) and mypy [3] (they recently left 0ver!) for static analysis, black for code formatting (I really miss an opinionated formatter like this in other languages), etc. They also work just fine. Python tooling doesn't seem bad to me.
[1] https://python-poetry.org/ [2] https://github.com/astral-sh/ruff [3] https://mypy-lang.org/
- seanhunter 2 years agoThere is a new generation of Python tooling that is very high quality.
`rye` is the equivalent of `cargo`
`ruff` is the equivalent of `clippy`
Both are single-purpose, highly-functional and blazingly fast. Both written in rust actually :)
- r4indeer 2 years ago
- 9dev 2 years agoThrowing out the unpopular opinion here: PHP! For all the hate it gets, the package ecosystem is really great. Libraries follow Semver (because the package manager, composer, requires it), quality is usually high, even for less widely used packages, and compatibility is taken seriously.
- zetalyrae 2 years ago
- seanhunter 2 years ago