New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
API stability review #751
Comments
Thanks a ton for putting this together, @mtrmac! For now, just a quick comment as I am still catching up with emails and GitHub.
Although I initially liked the idea, I have changed my take on that. Marking certain parts as unstable would certainly make our lives much easier but it would turn into rather big troubles for downstream packagers. Debian, in particular, is putting all go packages into separate deb-source packages and they rely on semantic versioning. Assuming we would mark certain parts as unstable and would introduce breaking changes but not don't bump the major version, the Debian packages might not compile anymore. |
Well, we can try… but it’s not quite clear that we can get that done. Consider the most common cases of API breaks, where //// types/types.go
type ImageDestination interface {
Method(OriginalParams) ReturnType
}
type ImageDestinationExt42 interface {
ImageDestination
MethodWithExtra(OriginalParams, ExtraParam) ReturnType
}
//// copy.go
func destMethod(dest ImageDestination, orig OriginalParams, extra ExtraParam) ReturnType {
if dest, ok = dest.(ImageDestinationExt42) {
return dest.MethodWithExtra(orig, extra)
}
return dest.Method(orig)
}
// and call destMethod(dest, orig, extra) instead of dest.Method(orig, extra) throughout
// Most transports can remain unchanged
//// storage/store_image.go
func (s *storageImageDestination) MethodWithExtra(…) ReturnType {
// actual implementation
}
func (s *storageImageDestination) Method(OriginalParams) {
// ⚠️
return ReturnType(errors.New("storage Method no longer supported, MethodWithExtra must be used by caller"))
} but
OTOH, if a particular transport has existed before But then again, if we introduced Ext42 to support a new transport that never existed before Ext42, there may not exist any reasonable way to implement that transport without the Ext42 information. Now, was that an API break for pre-Ext42 callers (because a declared API now breaks, and they can get such values through I guess one different way to think about this is that we want a different lifecycle, and versioning, for some of the interfaces like So, maybe two different Go modules in a single repo? That seems to be possible but with various gotchas, based on quick searches. But then again, that would not help Buildah, which, via |
… or should we just go all the way and declare |
💯, assuming we can find a public abstraction for Buildah to use the cache. Having those things internal would let us move faster and, maybe, sleep better :) |
I think at this point we have no appetite for moving to c/image/v6; the research in #1439 and the following merged changes to move a lot of the interfaces to |
WIP list of packages/interfaces to be kept / made private / changed.
Transport subpackage concerns:
For all the per-transport subpackages, we probably need to provide the
Transport
variable (but does that need to publicly support anything besidesName()
?) Or maybe make public transport-specific reference (source? destination?) types so that callers that must distinguish transports after-the-fact can do so using a type check instead of name comparison, and discourageName()
comparison.ParseReference
/NewReference
should be public in principle, but I’m not sure about committing to the all-in-onetypes.SystemContext
. MaybeImageReference
or onlyImageSource
/ImageDestination
? Moving that intoImageReference
would allow makingcopy.Image
SystemContext
-independent.)types.SystemContext
on top of the rest of c/image, liketransports/alltransports
, as a “create-reference-from-SystemContext-like-unstructured-options“ wrapper/helper.This uncertainty about
SystemContext
of course impacts the ability to commit toNewReference
/StableReference
. OTOH, I’d much rather have stable per-transportNewReference(systemContext, transport-specific-options)
than only to commit to string-syntaxalltransports.ParseImageName
as the only stable interface.(Cc: @vrothberg )
The text was updated successfully, but these errors were encountered: