strategy for vendoring in service libs

[joshgav]

we proposed factoring service implementations out of this repo and vendoring them in for more control

[tombuildsstuff]

👋 @joshgav - I might be mis-understanding this - but are you referring to each service implementation living in it's own repository; that's then vendored into the main repository?

[joshgav]

@tombuildsstuff yes, @marstr has been considering this. thoughts?

[tombuildsstuff]

@joshgav I'm not opposed to that - but as a consumer I can't help but feel that would make things more complicated to find things for new-comers (for instance, the AWS Repository has roughly the same number of services in the SDK and is all housed within a single repository). Digging through the archives I've got a more detailed response available in the original issue on Versioning)

Out of interest what's the benefit of taking approach? :)

[marstr]

"more control" what more do you want?

Just kidding, you know I wouldn't do that to you @tombuildsstuff!

So, as mentioned back in the issue you linked to (#517), we reorganized the repository to support all API Versions simultaneously. The big motivation being to reduce the frequency that we had to choose between offering the latest and greatest thing from the Azure services and staying stable. However, even with the updated pattern, we don't have a reliable mechanism for protecting ourselves from changes that were made to the Swagger definitions inside of an API Version. Sometimes these changes don't even represent something that look like a breaking change in the other languages' SDKs, but is a breaking change for us.

To solve this problem we have a couple of options:

1. Use a lock file during the generation process, locking individual packages to latest-known-good commits in the specs repository. A pro of doing it this way, is that there remains precisely one way to get a hold of any given package. The story is considerably simpler, especially for consumers who get curious about how this package is constructed. The downside, we wouldn't have a way for people to both use officially supported Go packages and target the latest REST API Spec.

2. Continue to have this repository, but have some of the packages swapped out with alias packages (the same as the ones in the profiles directory.) Taking this strategy would allow us to always always have an officially supported package for swaggers as soon as their published. The repositories that mapped to the services would aggressively stay up-to-date, and have their SemVers bumped as appropriate. This repository would become a roll-up package that adopted the latest bits from the service repositories as soon as it could without violating any SemVer promises. The roll-up package would aim to only ever publish a major version every six or twelve months.

I'd love to hear your thoughts, given that context.

[marstr]

One piece of context that I should add, is that we're definitely going to be vendoring in some packages (i.e. strategy 2) for the storage team. The big example of this is the new blobs repository, which will eventually get vendored in here in a folder named blobs or similar.

[jhendrixMSFT]

After much internal discussion we've decided that we're not going to be taking this approach.