Fork go-mssqldb into the Microsoft organization on Github

[shueybubbles]

Intro

Greetings Go developers! My name is David Shiflet, and I am a member of the SQL Experiences team at Microsoft. We have made some investments in this driver to support various initiatives within Microsoft and we see further adoption of this driver as a great opportunity for widening the exposure of SQL Server to cloud native applications. The current maintainers and past contributors have created a great product which is rapidly becoming essential to business operations for a variety of enterprises and services.

Proposal

As @denisenkom and @kardianos are winding down their level of involvement in this project, we would like to adopt this code and keep its evolution going. SQL Server and Azure SQL Database represent a continuously growing ecosystem upon which to build applications. We believe this driver can play a key role in building those applications if we and the Go developer community work together to

• expand its capabilities,
• improve its performance, and
• keep a high quality bar for pull requests.

We believe forking this repo to the Microsoft organization offers the best path to achieving those goals. As maintainers, the SQL Server Experiences team can assure potential customers that this driver has our complete backing as suitable for enterprise applications. As we build our own applications with this driver to work with new versions of SQL we will keep the driver itself up to date as part of our normal engineering work. We are also staffed to keep engaged with the community by taking pull requests and prioritizing issues to fix.

We will invite @denisenkom and @kardianos to be maintainers so they can continue to provide valuable insight. We welcome community nominations for other non-Microsoft maintainers.

What would the development/contribution process look like in the new fork?

Our first goal for the fork would be to create a v1.0 version of the driver. That version would come from taking PRs and fixes for existing issues that members of the community vote on as being of most immediate import. We will create Github project for V1.0 and ask the community to tag their issues and PRS with V1-Candidate to be evaluated for inclusion in that project.

We will enable Discussions on the project so conversations about prioritization and feature roadmap can take place in a more suitable forum than Issues. We will use Discussions to talk about the V1 candidates and rank them. We envision V1 as a version whose changes could be pushed back to the original denisenkom project.

Ideally V1 work would complete by mid-2022. We will then create a V2 project and start opening/assigning issues to it. By then we will have some discussion going for specific needs in the product roadmap, but at a high level V2's focus would be to bring the driver up to parity with cloud-relevant features that other Microsoft SQL drivers have. We want to get the go-mssqldb driver listed in our feature support matrix and turn key cells of the matrix to Yes values for the Go driver, including new features coming online over the next year in SQL Server 2022 and Azure SQL Database.

A key focus for V2 will be security, particularly moving to secure defaults for encryption. We will add support for TDS 8 which involves server negotiation using TLS and other security enhancements.

Additionally, we would replace the appveyor validation environment with GitHub actions that test the driver against modern instances of SQL Server 2017+ and Azure SQL Database. Given our focus is on modern Go and SQL development, we would reduce the support matrix down to Go 1.16+ and SQL Server 2017+. We believe the customers needing older versions of Go or SQL can get by with the existing denisenkom driver.

What are the next steps?

Please provide your feedback on this proposal by April 8 so we can incorporate it into our plans. I plan to create the fork ~March 30 but there's a fair amount of work involved to get it ready for public consumption, including updating it with our readme/contributing/code of conduct guides etc. We need to establish the github actions for running the tests to validate PRs. Our goal is to open it up for Discussions by April 8 and for PRs by April 25.

What could we use help with?

I know there are contributors here way more fluent in Go and module development practices than we are. Please let us know what best practices for versioning and testing are essential to incorporate into our fork. Where else should we publicize this issue to solicit feedback? How should we approach getting this fork into the "official" Go packages documentation and list of SQL drivers? Would the driver benefit from an effort to pass the compatibility test ?

I look forward to continuing this journey with the Go developer community and making SQL Server a great database platform for cloud native applications.

[tc-hib]

Hello, this would be great. I hope Microsoft will dedicate enough resource to this project.

But I wonder why you should drop support for older SQL Server versions, specifically from 2008 to 2016. In my company we use 2014 in a private network and we don't plan to upgrade as we don't need new features.

[chandanjainn]

Hello, this would be great. I hope Microsoft will dedicate enough resource to this project.

But I wonder why you should drop support for older SQL Server versions, specifically from 2008 to 2016. In my company we use 2014 in a private network and we don't plan to upgrade as we don't need new features.

Agreed. Dont see a reason to drop earlier versions of SQL servers. I believe we should be supporting Sql Server 2012+ min. Let us seek inputs from the community on this? Are there any stats available for the %age of the users on different versions?

[LessTravelledWay]

Hi David

I head up the Software Architecture function at Hillside Technology, part of the bet365 Group. I see this as a positive move in terms of ensuring the durability of this driver and continuing it's relevance. As a technology business we are heavily invested in both go and MS-SQL and therefore have a vested interest in improving this driver and ensuring it remains current.

To this end @PeteBassettBet365 has submitted a number of pull requests which make these significantly more performant as well as support for Kerberos authentication. On going, I am keen that we remain actively involved both in maintaining and contributing to the feature road map as part of the wider go community.

I would also question the proposed minimum SQL server version for V2. Given that 2014 isn't out of support until July 2024, I would suggest that, at least the first milestone version, should include support for SQL Server 2014+.

[shueybubbles]

thanks everyone for the considered and productive feedback! I will embark on the fork creation today and get the process going. There are a bunch of logistics to work out like whether we can keep the Appveyor-based PR validation in place while we bring new Github actions online. I will keep the community informed of progress using Discussions in the new fork. As for which version of SQL is the "minimum" I think we'll be fine testing against SQL2012+. In my experience as the maintainer of other SQL Server libraries (particularly https://github.com/microsoft/sqlmanagementobjects) the cost of assuring full backward compatibility can be very high relative to the benefit to users. Typically new features/enhancements for a driver or a library are targeted at the newer versions of the server such that people using old server versions can stay with the older library to avoid risks of regressions. With this driver, the situation is different because it's not really SQL/TDS features that are still in flux, it's the environment hosting the application built with the driver that has evolved. With that in mind, I feel it's important to look at every PR with a critical eye toward modularity/coupling/cohesion. For example, there are a couple PRs that address Kerberos authentication on Linux. They take different approaches to enabling different methods for integrated authentication. We should evaluate each approach for how it isolates each component from risk of regression or enables app developers to avoid pulling in code that isn't relevant for their environment. EG we tried to avoid injecting Azure Identity dependencies into the core driver such that apps that don't want it don't have to pull in that package.

I'll be in touch again soon, hopefully over in a new fork!

[bmanosh-sf]

@shueybubbles, I'm excited to hear about your support for this, thank you.

[keith6014]

@shueybubbles any word on the fork?

[shueybubbles]

We are on schedule to open up for PRs by the end of this week. https://github.com/microsoft/go-mssqldb Please open Issues and tag them with V1-Candidate.

[kardianos]

That sounds like a fine plan. Thank you. Sorry for disappearing; work got very busy.

[shueybubbles]

The microsoft fork is open for business! https://github.com/microsoft/go-mssqldb Please open Issues and tag them with V1-Candidate.