Migrating Service Bus code for the latest SDK to the central repository

[mayurid]

Move code from https://github.com/Azure/azure-service-bus-go to https://github.com/Azure/azure-sdk-for-go/

[devigned]

@mayurid, a few questions:

• What about the Azure Storage libraries? Will these libraries be moved into this repo as well?
• Will the Event Hubs library move into the central repository?
• Are there other libraries which will be moved into the central repository?
• The Service Bus library uses Golang modules, will that remain the case after the move to the central repository?
  • I ask since the central repository currently does not version with go modules.
• If these repos are moved, how long with the existing repos remain? Will they remain indefinitely?
  • Hopefully, they will remain as removing the repo would impact Golang software with existing dependencies on these libraries.
• Are there other alternatives being weighed?
  • Is is possible to keep these libraries in their current repo and just alias them into the main repo?

Thank you ahead of time.

[mayurid]

@devigned : Answering the questions in order:-

1. Yes we will be looking into that
2. Not in the near term but eventually we would like to see all new development happen in the Go repository
3. Right now the only one's in our list are Storage, EH and Service Bus. Please let us know if there are more which we should look into
4. We are planning to move the Go repo to version with Go Modules. We are working on phased plan for that. To begin with the we will make sure newer to repo libraries like SB, EH etc will be using it
5. Yes they will be kept around for the near future but no new development will be done there. We will give appropriate heads up to make sure customer impact can be minimized
6. We have discussed keeping existing repos around but would prefer having them centralized. SB will be the first one where we will do this move. if we run into issues we will reassess the plan.

Really appreciate your questions. Keep them coming

//cc : @jhendrixMSFT

[devigned]

3. Application Insights is one that comes to mind and would be super useful.

5/6. Perhaps, leaving the repos as archived would be a kinder approach than deleting.

It would be really helpful to publishing proposals for wide impacting work like this. I'd imagine it would be surprising if things like this happened abruptly.

[richardpark-msft]

Added in #15245 to deal with some of the mechanics of this transition for Service Bus.

We've pinned @devigned's issue discussing this in the azure-service-bus-go repo (Azure/azure-service-bus-go#152). The repo's issue tracker is fairly low traffic, even for issues, so we're not expecting too much feedback via that channel at the moment.

Code for track 2 has 'started' (literally just copied over as of this moment) in https://github.com/azure/azure-sdk-for-go/tree/track2-servicebus

[serbrech]

About 6. I agree with @devigned.
deleting the repo means existing software relying on it will stop compiling.
Comparing it to .NET, it would be the equivalent of deleting all nuget packages ever published for a project (not just deleting the repo)
Can we consider archiving the project instead?

[richardpark-msft]

@serbrech - Absolutely. Archiving is the only path we're considering (and is what we've done in the past as we've transitioned repos into the monorepo).

[richardpark-msft]

Also, I've updated the title as it's less of a "move" and more of a "we're starting the new SDK development in the monorepo".

[RickWinter]

The code and module for latest azservicebus is available at: https://github.com/Azure/azure-sdk-for-go/tree/main/sdk/messaging/azservicebus