Please release 1.0.3

[siretart]

I'm writing as a package maintainer for this repository in Debian and Ubuntu. Both distributions currently ship the most recent public release, which was released in November 2021.

These releases help as important syncronization point across all software packages in Linux software distributions so that consistent versions are being used. This is becoming increasingly and increadibly difficult as upstream such as buildah started to ship their own modified versions that cannot be found in the latest upstream release.

Newer upstream releases make my life significantly easier as then I don't have to disable features / revert commits that require newer fields.

Thank you for your consideration.

[sajayantony]

Could you give an example of this?

I don't have to disable features / revert commits that require newer fields.

Releasing without any changes seems a bit odd.

update -
I was wrong here. Seems like the data field was merged after that.
bac4452

[sudo-bmitch]

This raises the question about the ordering of releases. Frequently we like to be a lagging spec that sees some usage of a new feature before adding the standard, since that usage may reveal issues in the spec changes. That means that other projects will frequently have these newer features before a release, and often before a PR is approved. But the extensibility policy of the spec, to ignore unknown fields, means it should be safe for projects to do that experimentation without impacting a Linux distribution's ability to release that project.

[siretart]

@sajayantony gentle ping. Any chance to see a 1.0.3 release anytime soon?

thank you!

[sudo-bmitch]

I'm still not sure I fully understand what Debian is doing in this use case (saying that as both a Debian user and Go developer). Are you downgrading dependencies in projects to only released versions, and then backing out any features that depend on newer features? If so, that feels fairly broken as a Go developer (I could understand pulling in newer dependencies for security fixes).

There shouldn't be a need to interoperability between projects to use the same image-spec version or commit, each tool should support the features it recognizes, and ignore any unknown features.

We're currently working through the output of the working group to get that merged, and I expect there will be some hesitation to make a release with that for a few months to give time for tools to test the new features and report back any changes we need to make. I think we'd call that eventual release v1.1.0. While that is being tested, we could probably work on a v1.0.3 release that includes everything up to that change.

[siretart]

Are you downgrading dependencies in projects to only released versions

I wouldn't call it downgrading, but rather "unvendoring" and using "system-wide" copies of libraries to avoid the number of different version for each component.

we could probably work on a v1.0.3 release that includes everything up to that change.

That would be very helpful and exactly what I'm asking for. Thank you!

[sudo-bmitch]

With the 1.1.0 release, I believe we can close this out. My apologies that we weren't able to make an interim release happen.