Restructure repository to move sdk components into a lower directory
See original GitHub issueTo enable the introduction of other top-level components into the repo (e.g. the azure sdk BOM for Java, build tools, etc), it would likely make sense to move existing modules, for both management and data plane, into a subdirectory. This would clean the root level directory and prevent overload for users arriving at the github repo.
A proposed structure might take the form:
sdk\<service1>\client\src
sdk\<service1>\management\src
sdk\<service2>\client\src
sdk\<service2>\management\src
Issue Analytics
- State:
- Created 5 years ago
- Comments:9 (9 by maintainers)
Top Results From Across the Web
How to move some files from one git repo to another (not a ...
Go through your history and files, removing anything that is not in directory 1. The result is the contents of directory 1 spewed...
Read more >Moving and Renaming Files on GitHub
To move a file up, place your cursor at the beginning of the filename field and either:
Read more >Git submodule - Atlassian
A git submodule is a record within a host git repository that points to a specific commit in another external repository. Learn more...
Read more >Using multiple Git repositories instead of a single one ...
If you go with a single repo, you might run into issues with your internal ... to reorganize the CVS/SVN directory tree into...
Read more >Upgrading your build from Gradle 6.x to the latest
In Gradle 7, both the compile and runtime configurations are removed. Therefore, you have to migrate to the implementation and api configurations above....
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
@jianghaolu can probably give you more information but my understanding is that we ship multiple parallel packages one for each API version.
I would suggest starting with the data-plane libraries and then working with folks on the management team to stage the move of the management libraries.
Starting to get across what is required here. Can someone explain the backstory on the management libraries that have date folders? e.g.
/keyvault/resource-manager/v2015_06_01
. Assuming these are ARM API versions. Do we ship both versions of the packages or is one locked in time?