Please publish a stable interface (1.0) and consistent release notes

[kurtisvg]

Is your feature request related to a problem? Please describe.
denisenkom/go-mssqldb has been around for a few years and does not have a 1.0 version. This fork is the successor of that library, and has had several breaking changes. Releases are being tagged (e.g. https://github.com/microsoft/go-mssqldb/tags) which means new versions are rolling out to Go users, but the Releases doesn't have any release notes for these changes.

Relying on and updating to this library is painful - more breaking changes could occur at any time, there's not a good digest of those changes, meaning that it's hard to use this library in it's

Describe the solution you'd like
Two things:

1. Adopt a consistent release schedule and publish release notes. There's automation that can help such as ReleasePlease that can help make this easier and more streamlined.

2. Release a 1.0 and stop pushing breaking changes without a major version bump. Add some proper e2e tests of the public API that will alert with the public API has been broken. Signal to users that they can rely on this library and don't need to worry about the API breaking suddenly.

Describe alternatives you've considered
N/A

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

[cmMcKeevek]

v1.6 and v1.7 are similarly pushed without any indication from the Release page. Are they ready for public consumption or not?

[shueybubbles]

We only push tags when we feel the accumulated commits are worthy of public consumption as an update. Do the Go tools prefer tags that have a Release associated with them?

[cmMcKeevek]

That’s good to know. This isn’t about the tooling as much as human verification. My team was troubleshooting an issue, examined the recent deployment for differences, found the package update, went to the release notes to look for possible clues or an explanation of the issue, found none, and then accused me of using “pre-release” versions in production. They then proceeded to revert from 1.17, to 1.16, to 1.15 (the last “official” release). We have since found that that didn’t help and tried different tactics. Kevin McKeever Senior Software Engineer ***@***.***

…

On Mon, Mar 18, 2024 at 2:18 PM David Shiflet ***@***.***> wrote: We only push tags when we feel the accumulated commits are worthy of public consumption as an update. Do the Go tools prefer tags that have a Release associated with them? — Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABMXSK6GXDGZ6KB2XPBQVF3YY5DYDAVCNFSM6AAAAAATQFBB22VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBUHA4DOMZVGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[erezrokah]

Hi @shueybubbles thanks for the response. As mentioned by @cmMcKeevek go tooling can work with tags and even with commits sha. However humans and other tools that handle automatic updates of dependencies expect the following:

1. Patch bump - denotes a bug fix (e.g. 1.0.0 -> 1.0.1)
2. Minor bump - denotes a feature (e.g. 1.0.0 -> 1.1.0)
3. Major bump - denotes a breaking change (e.g. 1.0.0 -> 2.0.0)

This, as long with a changelog file and a release with a description of the changes, helps humans and dependency bots understand what to expect when updating versions.
For example we use Renovate to auto merge PRs that have non breaking updates (minor or patch bumps), but leave major bumps for humans to verify