Your version numbers are unconventional. Have you considered using semantic versioning?
cc @divega
For example, following semantic versioning (at least to the extent that we follow it in other .NET projects), the version of the latest Microsoft.Data.SqlClient preview package would have been something like 1.0.0-preview4.19221.1
instead of 1.0.19221.1-Preview
.
Thought now that you have used up to the 19221 patch version, not sure what is the best way to fix it and still get a good RTM version (which ideally would have been 1.0.0) that sorts after your existing previews.
@bricelam any suggestion for this?
cc @cheenamalhotra, @David-Engel
1.0.2 ?
Hi @bricelam @divega @ErikEJ
We will implement this semantic of versioning post GA and Open Sourcing driver, also automating MyGet Package publishing on commits with new CI practices.
@cheenamalhotra What version string to you plan to use for the 1.0.0 GA release?
We plan to keep the same template for now, as was done was last previews, and omitting '-Preview' suffix.
@cheenamalhotra So you're GA release will be 1.0.<some number greater than 19221>
? For example, 1.0.20000
? That's going to look really strange... What will your first patch release be?
@ajcvickers There are probably dependency considerations in your mind that we might be missing. Our plan was for more frequent minor version releases (2-3/year) and a "get on the latest minor version which will be backwards compatible" rather than frequent patch releases. Patch releases (if any) would simply be 1.0.
What advantage would changing the versioning bring?
Hi @bricelam @divega
We have updated our versioning to be in alignment with SemVer.
Future releases will address this change.
Awesome! I think this will do a lot of good for customer perception. The more consistency between Microsoft-released .NET libraries, the better.
Most helpful comment
Awesome! I think this will do a lot of good for customer perception. The more consistency between Microsoft-released .NET libraries, the better.