Add sdk project level version

[bzhou-sw]

Is your feature request related to a problem? Please describe.

Currently we see release tag for each module, like azure-storage-queues_12.0.0 , azure-storage-common_12.2.3, etc. It will be very helpful to have top level version tag and built-in version string in cmake file.

Describe the solution you'd like

We use both azure sdk and aws sdk. Example of what aws sdk does: https://github.com/aws/aws-sdk-cpp/blob/ce9e5c1d201542c567ad316d790ccc42e234987a/CMakeLists.txt#L148 https://github.com/aws/aws-sdk-cpp/blob/main/cmake/initialize_project_version.cmake

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Additional context Add any other context or screenshots about the feature request here.

Information Checklist Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• [x] Description Added
• [x] Expected solution specified

[RickWinter]

AWS is a monolith SDK and therefore a single version makes sense. The Azure SDK for C++ uses independent service packages released via vcpkg (or acquired from source). Each package has its own version information.
Example: azure-core

[ghost]

Hi @bzhou-sw. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text “/unresolve” to remove the “issue-addressed” label and continue the conversation.

[bzhou-sw]

/unresolve Thanks for your reply. When using multiple components, what user cares is a stable sdk version. Users usually don't upgrade components separately, instead they will just move to a new release tag which will include changes to all modules up to that HEAD commit, right?

[jepio]

Interested in this. I was looking at creating a DEB package for this SDK to make it easier for me and others to develop against, but stumbled when I couldn't find a version number to assign the package.

Packaging in general makes a reasonable assumption that sources are versioned and even if several components/subpackages are involved, you can trace it back to a single source version. I understand that different parts of the SDK are probably developed by different teams, but since they live in a single repo, a single version number helps consumers.

I also think like @bzhou-sw that users want to consume the SDK in a consistent state, and won't try to assemble different versions of subpackages (even more so considering that dependency requirements are regularly bumped together).

[github-actions[bot]]

Hi @bzhou-sw, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.