Liminix is 1.0 today!

[dan@loaclhost:~/src/liminix]$ git tag -a v1.0.0 -m 'Release 1.0'
[dan@loaclhost:~/src/liminix]$ git push origin v1.0.0
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), 163 bytes | 163.00 KiB/s, done.
Total 1 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
remote: . Processing 1 references
remote: Processed 1 references in total
To gti.telent.net:dan/liminix.git
 * [new tag]         v1.0.0 -> v1.0.0

  • we think it’s useful (empirically: I’ve been using it for more than a year, I know it’s useful for me)

  • we have addressed the findings in the security audit

  • there’s a refreshed/updated manual (which, incidentally, is now converted from Sphinx to Asciidoc)

What does this mean?

In essence it means that future breaking changes in Liminix will be signalled through the version number. I’m aiming for “semver-adjacent”, where minor bumps (1.1, 1.2 …) are used for minor new features and major bumps (2.0 …) for changes that are likely to break out-of-tree modules or configurations. It won’t be semver exactly because every change breaks someone’s workflow but we aspire to have the magnitude of the version delta correlate with the scale of the consequences of upgrading.

It doesn’t mean I regard Liminix as “finished”, because I don’t think that will ever happen. Nor is it a promise that you will find it useful or reliable or bugfree - though obviously we’re keen to find out where it isn’t.

What’s next

In 1.1, some better way of specifiying firewalls than a thin-but-still-frustrating veneer over nftables