Closed icecrime closed 8 years ago
I'd prefer option 1 since with golang people can just vendor it "as is" and not have to worry about whether "master" of docker is, or is not, master on the APIs. People will just know they're always at the same level. Plus, a tag of docker will automatically cover both areas. We don't need to worry about tagging 2 repos.
I would concur with @duglin. Absolutely though, trying to bring these back together in some manner that remains architecturally clean is goodness and makes life (for me at least - others might disagree :innocent: ) significantly easier.
Although I like engine-api
a lot (it's smaller to get than docker/docker
when vendoring :stuck_out_tongue_closed_eyes:), I think it has to be done at some point :sweat_smile:. The code in engine-api
is to tied to docker/docker
anyway so…
If we do it, I also prefer option 1 ; given also that we do something like #358 too 👼…
Agreed with option (1). For #358 we can just create a completely new repo with a better name.
FWIW 1,646 projects on github import the types package here alone... do you have a plan for informing people?
@jfrazelle we are not going to delete this or anything. Existing imports will continue to work.
I'm sure we can add this change in the next release notes, etc so that people can get the updated client in the next release.
maybe a warning on init or something though? idk if that is more pain though for people
Ya, i thought about that but if that happens to me I usually freak out because some package is logging messages in my program.
I'll update the readme in this repo as a start and trying to think of a way to notify the people.
Problem statement
The
docker/engine-api
repository was created to create a true decoupling between Engine internals and its public interface. A lot of valuable and solid refactoring came out of it, but today, most maintainers are complaining about the operational trade-offs it incurs.Proposal
The content of this repository will be moved back as a sub-package of
docker/docker
. We absolutely want to preserve the architectural boundary, but we want to remove the repository boundary which is too cumbersome.Under that scenario, what should we do with the
docker/engine-api
repository?github.com/docker/docker/api/client/
(exact path TBD).github.com/docker/docker/api/client/
(exact path TBD).I'm curious about your opinions @vdemeester @ibuildthecloud.