Maintainance Status?

[dudicoco]

Hi,

What is the status of this project?

There haven't been any releases since 2021 and the last commit from a human is from 8 months ago.

Also there have been discussions about building binary releases for mac but it didn't happen.

[cyphar]

The main reason there hasn't been a release is because we would want to do a release with the latest image-spec version, but:

1. opencontainers/image-tools is unmaintained, which means that the validation tests we do in umoci's CI won't work if we update the spec version. The only solution for this would be to merge image-tool's validation into umoci (migrate "oci-image-tool validate" to umoci #361), but I haven't had time to work on this (this would require subtree merging the repo, then reworking all of the code to work as an umoci subcommand, and then updating the specification tests to match the new specification).
   • This will also require some minor updates to umoci itself, but we can't do those until we can update the spec version without all of CI failing due to the validation tests.
2. The story is similar for the runtime-spec update -- runtime-tools is getting patches still, but there hasn't been a release since 2019 which means we cannot update the runtime-spec version until runtime-tools has an update. Also, since the tooling is 2019-era tooling, there are some other issues -- I sent release 0.9.1 runtime-tools#774 last year to try to rectify the situation, but there hasn't really been an update (there is some really unfortunate Go behaviour that makes doing releases like that very hard). I guess we should just do a 0.10.0 release from current HEAD.
3. I am currently working on libpathrs. Once libpathrs 0.2 is released, my plan is to migrate umoci to using it first (before we migrate runc) in order to find any obvious issues in libpathrs. This isn't a blocker for the next umoci release, but it does mean I have less time to work on (1) and (2).
4. The only key work that needs to be done at the moment is (1) and (2) so there's not a lot of other patches to work on, hence less activity. Doing a rework of Add 'umoci copy' subcommand #359 has been on my to-do list for a very long time, but it's not clear whether such a tool is within scope of umoci as an OCI tool (is a reference implementation of distribution-spec part of being a reference implementation of image-spec?) and there are other tools that are far more popular for this (skopeo and ocas) so it's not clear whether the work will be justified (though it would be nice). So it's lower priority than (1) and (2), which I don't have time for.
5. There aren't a lot of patches being sent, so there isn't a lot for me to review/merge. Hence why I've mostly just been merging dependabot updates for the past while.

To be clear, I don't like the current situation, but there's only one of me so some things just take time until I get enough bandwidth to work on them.

Also there have been discussions about building binary releases for mac but it didn't happen.

My previous comment in #505 (comment) still stands. You can build MacOS binaries using go get/go build very easily, but the tests we run on MacOS are quite superficial and so I don't feel comfortable saying that they're "supported" in the same way Linux is. If someone is willing to get the integration tests working on MacOS, that would be a different story (I don't use MacOS so I can't test anything locally).

[dudicoco]

Thanks for the extensive information @cyphar.

[tych0]

For my part, I used umoci-the-library-and-command-line at my last $dayjob, and umoci-the-command-line at my current day job, and both do what I need, so there's not a lot of need to do things besides any security patches, which mostly we haven't had.

[cyphar]

Yeah we still use umoci extensively at SUSE for building container images (which was the original need that motivated me to write umoči), so it's still used by a fair number of people. I would like to get more things done but the to-do list of minor work to do is a little short. (However, this issue made me go look through old issues and I'll probably send a patch updating to Go stdlib errors since that is long overdue and is fairly simple.)