Common-utils installation feature after refactoring

[mml5bg]

We had an issue with installation of common-utils feature what is solved with following workaround added in our Dockerfile.

ADD https://raw.githubusercontent.com/devcontainers/features/7fa90110d762797cc0b1c2fe8fcc028c9b813d56/src/common-utils/install.sh /tmp/scripts/install-common.sh

But, we want to support latest version of common-utils feature and current workaround doesn't work with latest changes (refactoring of common-utils feature). Could you help us with this?

Hint: We would really appreciate if you could introduce tags when you are applying breaking changes.

[emsameen]

Thanks, I have the same issue and don't find any release or tag to add my reference to, the only possible solution for me was to use the hash of the last working commit which from my opinion is not an optimal solution and would appreciate if we could get a tag or release candidates tag before introducing a big refactoring that may lead to breaking changes ;)

[samruddhikhandale]

Hi 👋

Have you tried adding the Feature to a devcontainer.json and by pinning a major version?

Example 👇

https://github.com/devcontainers/features/pkgs/container/features%2Fcommon-utils/63419891?tag=2

"features": {
  "ghcr.io/devcontainers/features/common-utils:2": {}
}

We follow semantic versioning and if there's any breaking change, then we'd bump the major version.

[jkeech]

We've started tagging all feature releases (#422). There's now a feature_common-utils_2.0.8 tag, and subsequent releases will add a new tag for the new version.

That said, I agree with Samruddhi Khandale (@samruddhikhandale) that it would be better to depend on the feature itself rather than a script within the feature repo's source code. We don't provide any compatibility guarantees about scripts within the feature since that's an implementation detail of the feature. The feature package and options are the public API that is versioned following sem-ver. Scripts inside the feature package can be refactored without being considered a breaking change if the functionality does not change. Directly consuming the scripts is like calling a private class member through reflection rather than the going through the public interface.