Please tag new release

[onlyjob]

Current release 2.6.2 provides no github.com/docker/distribution/digestset which is used by the current "stable" release of Docker.

Please tag new release so Docker/Moby could use semantic vendoring instead of random commit.

Thanks.

[onlyjob]

Lack of recent release forced developers of github.com/appc/docker2aci to vendor commit (5db89f0) which is ahead of current/latest release v2.6.2...

[sargun]

Any chances of a 3.0 or 2.7?

[dmcgowan]

We have a milestone for 2.7 https://github.com/docker/distribution/milestone/18. Once the large items there are cleared out we will start considering a release.

Lack of recent release forced developers of github.com/appc/docker2aci to vendor commit

We don't consider this a problem worth releasing for. We release 2.6.x for stability or security issues, and 2.7.0 for features as seen in that milestone. We encourage people to choose a commit, test with that commit, and vendor it as is best practice in Go. We have been trying to spin out different parts of the code so that the project does need to be relied on as a client library.

[sargun]

@dmcgowan Can I make a suggestion? Can we groom that list to stability changes for 2.7 master only, and push the features on that list to 2.8?

[dmcgowan]

@sargun after the OCI change is in, will start punting and grooming for a release

[sargun]

Which OCI change?

[sargun]

This one: #2076

[onlyjob]

We release 2.6.x for stability or security issues, and 2.7.0 for features as seen in that milestone.

Fair enough. Then perhaps releasing more often would help.

We encourage people to choose a commit, test with that commit,

This is incorrect because it defeats the purpose of semantic versioning.
Golang runs no tests for vendored libraries. Ideally library should provide some indication of stability and semantic versioning is a very effective tool for that.
It helps to track new releases; helps with transitions as one knows what to expect when upgrading the library (if it is semantically versioned), etc. It is helpful to downstream maintainers and allows to package reusable libraries and build software with common (not private) dependencies (which is the only way to provide meaningful security support).

and vendor it as is best practice in Go.

This is not a best practice. Quite the opposite, this is abomination of best practice regretfully proliferated in Golang.

We have been trying to spin out different parts of the code so that the project does need to be relied on as a client library.

It would be best to have formal (recommended) releases to encourage users of this library to vendor matching version of the library to the daemon provided by this repository.

[bcg62]

looking for a new release as well to utilize this

#1844

[dmp42]

@onlyjob @bcg62
We are actively working toward 2.7, which should land early this fall.

[onlyjob]

Until then this issue is outstanding and should remain open.