Reconsider removing v5 & v6

[davidcorrigan714]

@nechvatalp @nechvatalp Please reconsider how you all have restructured this library. It just broke a ton of our stuff with removing v6 & v5 code. In the old structure the various versions lived side-by-side so I think it's a fair assumption that people used liberal version restrictions assuming that the library would follow that pattern and not suddenly drop v6 from the code entirely.

[davidcorrigan714]

oh, didn't mean to ping you twice. Apparently some commits have your name and some have your GH handle.

[howardjones]

Same here. At least it's highlighted a few places in CI pipelines that should have versions pinned.

In the previous version the default clients were 5.1 and you needed to use v6_0 by name to get "new" features. So pretty much anyone using those is broken because that has suddenly gone away.

(awesome that there is some movement on this library though! thanks)

[davidcorrigan714]

Honestly it's probably better just updating everything at the base level and matching it to the library version but as you mentioned you previously had to explicitly import v5_1 or v6_0 before to get the current version of the API which was required in most cases these days as the stuff at the root level was pretty stale at this point. Our python folk are having fun fixing up a few requirements files and discussing the finer points of version pinning.

Also just really glad to see this and the Go library updated. Hoping that means the process is figured out again for more updates in the future.

[nechvatalp]

Sorry for breaking you, but it is a major version change so some breaking changes are to be expected. I followed the setup that was created by the previous maintainer which was to have the released clients, latest stable API and preview API versions. Maybe we could at some point have something like a released, stable, preview instead of having the version which can change in the path, so it would try to use the new API versions without straight up import failures. Good news is that many more APIs are now in the released I would recommend using that as much as possible.

[davidcorrigan714]

There's a really big maintenance issue with the update to the structure. By putting each API version in a folder but not including old versions like before, it makes upgrading clients really really annoying. It's not like you can just update the package and run some tests, every usage of the library has to change which is a ton of work across all of our scripts. In the past the code using say v5 could continue to use v6 and we could just do import git_client from azure_devops.v7 for example to start using v7 in places where it's needed.