5 ms·

The most impressive thing is being on 0.9 after nearly 30 years

by sam0x17 11mo ago

grg0 11mo ago
It's so old, that the 3D icons and window borders will be new again when 1.0 is released. Talk about some long-term vision. But jokes aside, I always enjoy reading about custom OSes.
- WD-42 11mo ago
  You joke but the first thing I thought when I saw the icons was that they were nice. Flat everything has run its course.
ndiddy 11mo ago
https://0ver.org/ https://0ver.org/
- 65 11mo ago
  I always found semantic versioning a little too verbose. Particularly when deciding when to release major versions. OSX was on version 10 for many years but of course released a new "major" version every year. Semantic versioning is just something everyone does in software development, but is is really that necessary?
  - rswail 11mo ago
    Semantic versioning is for APIs, not for functionality. So it's for developers consuming that API (whether a library, or a service). For releases in production, use a calendar version. v2025-11-02 is a clear release tag. Add preciseness as required. There should be a SBOM/Manifest (Bill Of Materials) of the versioned major components and configuration for that overall release. For users, it depends on the type of user and what they expect. Their focus is on functionality. So when there's a new feature, bump the number. It's a bit like the car model. It can be random extension letters like "-X", or "6Si".
    - necovek 11mo ago
      Developers are "users" (of a library, API, tool...), and "API functionality" is a subset of "functionality": what purpose would such distinction serve? For example, in end user desktop software (say a text editor), how would you indicate a security bug fix for an old version v2023-11-02 without forcing users to pay for a new version of v2025-09-15? Again, versioning is a tool, and depending on the release structure of a project, SemVer might work well or it might not (including for APIs/libraries).
      - rswail 11mo ago
        Semver is semantic. It tells you about the changes in the API, not in the implementation. So it's relevant to the users (ie developers) of that API. If I fix a bug in the implementation that doesn't affect the API itself, the semver doesn't change. So it works to define the versioning of an interface. Release versioning (like vyyyy-mm-dd) is about SRE and configuration management, it's about documenting what is actually operating in production. User versioning is about user expectations. If you're doing a security bug fix, then a) it should be free to users affected, and b) it should be documented as the reason for the release. For a security bug fix of v2023-11-02, you can add a "hotfix" extension to the numbering so v2023-11-02.001 or equivalent.
        necovek 11mo ago
        I can see how you are using the multiple versioning schemes to achieve certain goals, but that does not make your approach "one true way". "Semantic" really means "has some background meaning", and SemVer meaning behind all the numbers is in no way limited to API versioning: I am confused if you are making a proposal to consider it only that, arguing that different schemes should be used for different types of software, or stating that this is the only thing SemVer can be used for? On any of those points, I disagree and you haven't made a convincing argument why that would make sense. Note that I am not saying that SemVer is the only true way to do versioning (very much not so) for all software, just that it depends on your release strategy what is most applicable, and not on the type of software you are shipping.
  - necovek 11mo ago
    Versioning is a tool to communicate changes and backwards compatibility to the users. SemVer makes sense in a lot of cases, but it neither covers everything (eg. compare with Debian/Ubuntu packaging versions), nor is it always needed (think of REST API versions which usually only go with major versions, and commonly multiple major versions from the same codebase).
- GaryBluto 11mo ago
  > zerZerover Jesus Christ.

The most impressive thing is being on 0.9 after nearly 30 years

by sam0x17 11mo ago

The most impressive thing is being on 0.9 after nearly 30 years

grg0 11mo ago

It's so old, that the 3D icons and window borders will be new again when 1.0 is released. Talk about some long-term vision. But jokes aside, I always enjoy reading about custom OSes.

WD-42 11mo ago
You joke but the first thing I thought when I saw the icons was that they were nice. Flat everything has run its course.

ndiddy 11mo ago

https://0ver.org/ https://0ver.org/

65 11mo ago
I always found semantic versioning a little too verbose. Particularly when deciding when to release major versions. OSX was on version 10 for many years but of course released a new "major" version every year. Semantic versioning is just something everyone does in software development, but is is really that necessary?
- rswail 11mo ago
  Semantic versioning is for APIs, not for functionality. So it's for developers consuming that API (whether a library, or a service). For releases in production, use a calendar version. v2025-11-02 is a clear release tag. Add preciseness as required. There should be a SBOM/Manifest (Bill Of Materials) of the versioned major components and configuration for that overall release. For users, it depends on the type of user and what they expect. Their focus is on functionality. So when there's a new feature, bump the number. It's a bit like the car model. It can be random extension letters like "-X", or "6Si".
  - necovek 11mo ago
    Developers are "users" (of a library, API, tool...), and "API functionality" is a subset of "functionality": what purpose would such distinction serve? For example, in end user desktop software (say a text editor), how would you indicate a security bug fix for an old version v2023-11-02 without forcing users to pay for a new version of v2025-09-15? Again, versioning is a tool, and depending on the release structure of a project, SemVer might work well or it might not (including for APIs/libraries).
    - rswail 11mo ago
      Semver is semantic. It tells you about the changes in the API, not in the implementation. So it's relevant to the users (ie developers) of that API. If I fix a bug in the implementation that doesn't affect the API itself, the semver doesn't change. So it works to define the versioning of an interface. Release versioning (like vyyyy-mm-dd) is about SRE and configuration management, it's about documenting what is actually operating in production. User versioning is about user expectations. If you're doing a security bug fix, then a) it should be free to users affected, and b) it should be documented as the reason for the release. For a security bug fix of v2023-11-02, you can add a "hotfix" extension to the numbering so v2023-11-02.001 or equivalent.
      - necovek 11mo ago
        I can see how you are using the multiple versioning schemes to achieve certain goals, but that does not make your approach "one true way". "Semantic" really means "has some background meaning", and SemVer meaning behind all the numbers is in no way limited to API versioning: I am confused if you are making a proposal to consider it only that, arguing that different schemes should be used for different types of software, or stating that this is the only thing SemVer can be used for? On any of those points, I disagree and you haven't made a convincing argument why that would make sense. Note that I am not saying that SemVer is the only true way to do versioning (very much not so) for all software, just that it depends on your release strategy what is most applicable, and not on the type of software you are shipping.
- necovek 11mo ago
  Versioning is a tool to communicate changes and backwards compatibility to the users. SemVer makes sense in a lot of cases, but it neither covers everything (eg. compare with Debian/Ubuntu packaging versions), nor is it always needed (think of REST API versions which usually only go with major versions, and commonly multiple major versions from the same codebase).
GaryBluto 11mo ago
> zerZerover Jesus Christ.