Cheena Malhotra
6 years ago
committed by
GitHub
GitHub
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
10 changed files with 257 additions and 59 deletions
-
5CODE_OF_CONDUCT.md
-
80CONTRIBUTING.md
-
9COPYRIGHT.md
-
46README.md
-
5build.proj
-
26coding-style.md
-
87contributing-workflow.md
-
37roadmap.md
-
19src/Microsoft.Data.SqlClient/tests/Nuget.Config
-
2tools/vsconfig/VS19Components.vsconfig
@ -0,0 +1,5 @@ |
|||
# Code of Conduct |
|||
|
|||
This project has adopted the code of conduct defined by the Contributor Covenant |
|||
to clarify expected behavior in our community. |
|||
For more information, see the [.NET Foundation Code of Conduct](https://dotnetfoundation.org/code-of-conduct). |
|||
@ -0,0 +1,80 @@ |
|||
# Contributing to Microsoft.Data.SqlClient |
|||
|
|||
General contribution guidance is included in this document. Additional guidance is defined in the documents linked below. |
|||
|
|||
- [Copyright](copyright.md) describes the licensing practices for the project. |
|||
- [Contribution Workflow](contributing-workflow.md) describes the workflow that the team uses for considering and accepting changes. |
|||
|
|||
## Up for Grabs |
|||
|
|||
The team marks the most straightforward issues as "up for grabs". This set of issues is the place to start if you are interested in contributing but new to the codebase. |
|||
|
|||
- [dotnet/sqlclient - "up for grabs"](https://github.com/dotnet/sqlclient/labels/Up-for-Grabs) |
|||
|
|||
## Contribution "Bar" |
|||
|
|||
Project maintainers will merge changes that improve the product significantly and broadly and that align with the [Microsoft.Data.SqlClient roadmap](https://github.com/dotnet/sqlclient/blob/master/roadmap.md). |
|||
|
|||
Contributions must also satisfy the other published guidelines defined in this document. |
|||
|
|||
## DOs and DON'Ts |
|||
|
|||
Please do: |
|||
- **DO** report each issue as a new issue (but check first if it's already been reported) |
|||
- **DO** respect Issue Templates and provide detailed information. It will make the process to reproduce the issue and provide a fix faster. |
|||
- **DO** provide a minimal repro app demonstrating the problem in isolation will greatly speed up the process of identifying and fixing problems. |
|||
- **DO** follow our [coding style](coding-style.md) (C# code-specific) when working on a Pull Request. |
|||
- **DO** give priority to the current style of the project or file you're changing even if it diverges from the general guidelines. |
|||
- **DO** consider cross-platform compatibility and supportability for all supported SQL and Azure Servers and client configurations. |
|||
- **DO** include tests when adding new features. When fixing bugs, start with adding a test that highlights how the current behavior is broken. |
|||
- **DO** consider concurrency when writing tests. Our pipelines run builds and tests in parallel using the same client and server configurations (in an isolated mode). E.g. Consider using dynamic table/database object names instead of hardcoded values (Use existing tests for reference). |
|||
- **DO** keep the discussions focused. When a new or related topic comes up it's often better to create new issue than to side track the discussion. |
|||
- **DO** blog and tweet (or whatever) about your contributions, frequently! |
|||
|
|||
Please do not: |
|||
|
|||
- **DON'T** make PRs for style changes. |
|||
- **DON'T** leave any artifacts on server in tests or leave open resources. Cleaning up all objects is highly appreciated to maintain test server health. |
|||
- **DON'T** skip tests or run them conditionally unless necessary. If conditions are not met, test coverage will not be 100%. Use only pre-defined conditions that are already being run in pipelines. |
|||
- **DON'T** surprise us with big pull requests. Instead, file an issue and start a discussion so we can agree on a direction before you invest a large amount of time. |
|||
- **DON'T** commit code that you didn't write. If you find code that you think is a good fit to add, file an issue and start a discussion before proceeding. |
|||
- **DON'T** submit PRs that alter licensing related files or headers. If you believe there's a problem with them, file an issue and we'll be happy to discuss it. |
|||
|
|||
## Using Labels |
|||
|
|||
We encourage adding appropriate labels to issues and pull requests to allow filtering and analysis effectively. The below variables are required for new Pull Requests if applicable: |
|||
|
|||
| Label | Description | |
|||
| ----- | ----------- | |
|||
| [Public API](https://github.com/dotnet/SqlClient/labels/Public%20API) | Use this variable if a new Public API is added to the Pull Request. |
|||
| [Breaking Change](https://github.com/dotnet/SqlClient/labels/Breaking%20Change) | Use this variable if the Pull Request breaks an existing API. | |
|||
| [Backport to CoreFx](https://github.com/dotnet/SqlClient/labels/Backport%20to%20CoreFx) | Use this variable if the Issue/Pull Request needs to be backported to System.Data.SqlClient in [dotnet/corefx](https://github.com/dotnet/corefx) | |
|||
| [Managed SNI](https://github.com/dotnet/SqlClient/labels/Managed%20SNI) | Use this label if the issue/PR relates to issues in Managed SNI | |
|||
| [Tests](https://github.com/dotnet/SqlClient/labels/Tests) | Use this label for pull requests that add only tests to the repository. | |
|||
|
|||
## Reporting security issues and security bugs |
|||
|
|||
Security issues and bugs should be reported privately, via email, to the Microsoft Security Response Center (MSRC) [secure@microsoft.com](mailto:secure@microsoft.com). You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message. Further information, including the MSRC PGP key, can be found in the [Security TechCenter](https://technet.microsoft.com/en-us/security/ff852094.aspx). |
|||
|
|||
## File Headers |
|||
|
|||
The following file header is used for Microsoft.Data.SqlClient. Please use it for new files. |
|||
|
|||
```csharp |
|||
// Licensed to the .NET Foundation under one or more agreements. |
|||
// The .NET Foundation licenses this file to you under the MIT license. |
|||
// See the LICENSE file in the project root for more information. |
|||
``` |
|||
|
|||
## Contributor License Agreement |
|||
|
|||
You must sign a [.NET Foundation Contribution License Agreement (CLA)](https://cla.dotnetfoundation.org) before your PR will be merged. This is a one-time requirement for projects in the .NET Foundation. You can read more about [Contribution License Agreements (CLA)](http://en.wikipedia.org/wiki/Contributor_License_Agreement) on Wikipedia. |
|||
|
|||
The agreement: [net-foundation-contribution-license-agreement.pdf](https://github.com/dotnet/home/blob/master/guidance/net-foundation-contribution-license-agreement.pdf) |
|||
|
|||
You don't have to do this up-front. You can simply clone, fork, and submit your pull-request as usual. When your pull-request is created, it is classified by a CLA bot. If the change is trivial (for example, you just fixed a typo), then the PR is labelled with `cla-not-required`. Otherwise it's classified as `cla-required`. Once you signed a CLA, the current and all future pull-requests will be labelled as `cla-signed`. |
|||
|
|||
## Code Of Conduct |
|||
|
|||
This project has adopted the code of conduct defined by the Contributor Covenant to clarify expected behavior in our community. |
|||
For more information, see the [.NET Foundation Code of Conduct](https://dotnetfoundation.org/code-of-conduct). |
|||
@ -0,0 +1,9 @@ |
|||
# Copyright |
|||
|
|||
## Source License |
|||
|
|||
- The [MIT License](LICENSE) is used by this repository for [source code](https://github.com/dotnet/sqlclient/). |
|||
|
|||
## Binary License |
|||
|
|||
- **Microsoft.Data.SqlClient** binary distributions (nuget packages) are licensed as MIT (identical to the [Microsoft.Data.SqlClient source license](https://github.com/dotnet/sqlclient/blob/master/LICENSE)). |
|||
@ -0,0 +1,26 @@ |
|||
# C# Coding Style |
|||
|
|||
We follow a similar coding style as [dotnet/corefx](https://github.com/dotnet/corefx). |
|||
|
|||
For non code files (xml, etc), our current best guidance is consistency. When editing files, keep new code and changes consistent with the style in the files. For new files, it should conform to the style for that component. If there is a completely new component, anything that is reasonably broadly accepted is fine. |
|||
|
|||
The general rule we follow is "_use Visual Studio defaults_". |
|||
|
|||
1. We use [Allman style](http://en.wikipedia.org/wiki/Indent_style#Allman_style) braces, where each brace begins on a new line. A single line statement block can go without braces but the block must be properly indented on its own line and must not be nested in other statement blocks that use braces. One exception is that a `using` statement is permitted to be nested within another `using` statement by starting on the following line at the same indentation level, even if the nested `using` contains a controlled block. |
|||
2. We use four spaces of indentation (no tabs). |
|||
3. We use `_camelCase` for internal and private fields and use `readonly` where possible. Prefix internal and private instance fields with `_`, static fields with `s_` and thread static fields with `t_`. When used on static fields, `readonly` should come after `static` (e.g. `static readonly` not `readonly static`). Public fields should be used sparingly and should use PascalCasing with no prefix when used. |
|||
4. We avoid `this.` unless absolutely necessary. |
|||
5. We always specify the visibility, even if it's the default (e.g. `private string _foo` not `string _foo`). Visibility should be the first modifier (e.g. `public abstract` not `abstract public`). |
|||
6. Namespace imports should be specified at the top of the file, *outside* of `namespace` declarations, and should be sorted alphabetically, with the exception of `System.*` namespaces, which are to be placed on top of all others. |
|||
7. Avoid more than one empty line at any time. For example, do not have two blank lines between members of a type. |
|||
8. Avoid spurious free spaces. For example avoid `if (someVar == 0)...`, where the dots mark the spurious free spaces. Consider enabling "View White Space (Ctrl+E, S)" if using Visual Studio to aid detection. |
|||
9. If a file happens to differ in style from these guidelines (e.g. private members are named `m_member` rather than `_member`), the existing style in that file takes precedence. |
|||
10. We only use `var` when it's obvious what the variable type is (e.g. `var stream = new FileStream(...)` not `var stream = OpenStandardInput()`). |
|||
11. We use language keywords instead of BCL types (e.g. `int, string, float` instead of `Int32, String, Single`, etc) for both type references as well as method calls (e.g. `int.Parse` instead of `Int32.Parse`). |
|||
12. We use PascalCasing to name all our constant local variables and fields. The only exception is for interop code where the constant value should exactly match the name and value of the code you are calling via interop. |
|||
13. We use ```nameof(...)``` instead of ```"..."``` whenever possible and relevant. |
|||
14. Fields should be specified at the top within type declarations. |
|||
15. When including non-ASCII characters in the source code use Unicode escape sequences (\uXXXX) instead of literal characters. Literal non-ASCII characters occasionally get garbled by a tool or editor. |
|||
16. When using labels (for goto), indent the label one less than the current indentation. |
|||
|
|||
An [EditorConfig](https://editorconfig.org "EditorConfig homepage") file (`.editorconfig`) has been provided at the root of the sqlclient repository, enabling C# auto-formatting. |
|||
@ -0,0 +1,87 @@ |
|||
# Contribution Workflow |
|||
|
|||
You can contribute to Microsoft.Data.SqlClient with issues and PRs. Simply filing issues for problems you encounter is a great way to contribute. Contributing implementations is greatly appreciated. |
|||
|
|||
## Suggested Workflow |
|||
|
|||
We use and recommend the following workflow: |
|||
|
|||
1. Create an issue for your work. |
|||
- You can skip this step for trivial changes. |
|||
- Reuse an existing issue on the topic, if there is one. |
|||
- Get agreement from the team and the community that your proposed change is a good one. |
|||
- If your requested change needs a new public API, add a Label "**Public API**" to your issue. |
|||
- If your requested change address performance improvement in the driver, add a Label "**Performance**" to your issue. |
|||
- For any other improvements in the driver, add a Label "**Enhancement**" to your issue. |
|||
- Clearly state that you are going to take on implementing it, if that's the case. You can request that the issue be assigned to you. Note: The issue filer and the implementer don't have to be the same person. |
|||
2. Create a personal fork of the repository on GitHub (if you don't already have one). |
|||
3. Create a branch off of master (`git checkout -b mybranch`). |
|||
- Name the branch so that it clearly communicates your intentions, such as issue-123 or githubhandle-issue. |
|||
- Branches are useful since they isolate your changes from incoming changes from upstream. They also enable you to create multiple PRs from the same fork. |
|||
4. Make and commit your changes. |
|||
- Please follow our [Commit Messages](contributing.md#commit-messages) guidance. |
|||
5. Add new tests corresponding to your change, if nor present and applicable. |
|||
6. Build the repository with your changes. |
|||
- Make sure that the builds are clean. |
|||
- Make sure that the tests are all passing, including your new tests. |
|||
7. Create a pull request (PR) against the upstream repository's **master** branch. |
|||
- Push your changes to your fork on GitHub (if you haven't already). |
|||
|
|||
> Note: It is OK for your PR to include a large number of commits. Once your change is accepted, you will be asked to squash your commits into one or some appropriately small number of commits before your PR is merged. |
|||
|
|||
> Note: It is OK to create your PR as "[WIP]" on the upstream repo before the implementation is done. This can be useful if you'd like to start the feedback process concurrent with your implementation. State that this is the case in the initial PR comment. |
|||
|
|||
## PR - CI Process |
|||
|
|||
_[Coming Soon - Currently under development]_ |
|||
|
|||
The [SqlClient Continuous Integration](https://dev.azure.com/sqlclientdrivers-ci/sqlclient/) (CI) system will automatically perform the required builds and run tests (including the ones you are expected to run) for PRs. Builds and test runs must be clean. |
|||
|
|||
If the CI build fails for any reason, the PR issue will be updated with a link that can be used to determine the cause of the failure. |
|||
|
|||
## PR Feedback |
|||
|
|||
Microsoft team and community members will provide feedback on your change. Community feedback is highly valued. You will often see the absence of team feedback if the community has already provided good review feedback. |
|||
|
|||
1 or more Microsoft team members will review every PR prior to merge. They will often reply with "LGTM, modulo comments". That means that the PR will be merged once the feedback is resolved. "LGTM" == "looks good to me". |
|||
|
|||
## Merging Pull Requests (for contributors with write access) |
|||
|
|||
Use ["Squash and Merge"](https://github.com/blog/2141-squash-your-commits) by default for individual contributions unless requested by the PR author. |
|||
|
|||
Do so, even if the PR contains only one commit. It creates a simpler history than "Create a Merge Commit". Reasons that PR authors may request "Merge and Commit" may include (but are not limited to): |
|||
- The change is easier to understand as a series of focused commits. Each commit in the series must be buildable so as not to break `git bisect`. |
|||
- Contributor is using an e-mail address other than the primary GitHub address and wants that preserved in the history. Contributor must be willing to squash the commits manually before acceptance. |
|||
|
|||
## PR Verification and Validation |
|||
|
|||
For testing PR changes and ensure they work fine, we maintain a public feed that lists NuGet Packages built with merged commits. |
|||
|
|||
**Link to Public Feed:** [Microsoft.Data.SqlClient.Commits](https://pkgs.dev.azure.com/sqlclientdrivers-ci/sqlclient/_packaging/Microsoft.Data.SqlClient.Commits/nuget/v3/index.json) |
|||
|
|||
**Add this feed to NuGet Sources** |
|||
|
|||
```cmd |
|||
nuget.exe sources Add -Name "Microsoft.Data.SqlClient.Commits" -Source "https://pkgs.dev.azure.com/sqlclientdrivers-ci/sqlclient/_packaging/Microsoft.Data.SqlClient.Commits/nuget/v3/index.json" |
|||
``` |
|||
|
|||
### Pushing to Public Feed |
|||
|
|||
Maintainers of [dotnet/sqlclient](https://github.com/dotnet/SqlClient) manually push NuGet Packages to this feed after the PR is merged to the `master` branch and a commit ID has been generated on `master`. |
|||
|
|||
Not every commit is built and published on the public CI feed, but only the commits that make considerable difference to the driver will be uploaded in this feed. |
|||
|
|||
The label **Push to Commit Feed** will be added to the Pull Request if it is pushed to the feed. |
|||
|
|||
### Downloading Packages |
|||
|
|||
The package naming conventions follow SemVer 2.0.0 and also provide changeset information to ensure the right PR changes are being downloaded for testing: |
|||
|
|||
Package names will be like: `Microsoft.Data.SqlClient.1.1.0-build.19250.1-c21aa7c.nupkg` |
|||
|
|||
Breaking down: |
|||
- `1.1.0-build` - Identitier for currently active driver version in Build. |
|||
- `19250.1` - Unique identifier to keep latest PRs on top of the feed. |
|||
- `c21aa7c` - Short Commit Id to identify merged commit in `master`. |
|||
|
|||
> Note: This public feed is only for testing and validating new PR changes. Packages from feed will be eventually removed when the maximum NuGet Package limit of **50** is reached. We do not recommend using packages from this feed in client applications. |
|||
@ -0,0 +1,37 @@ |
|||
# Microsoft.Data.SqlClient Roadmap |
|||
|
|||
The Microsoft.Data.SqlClient roadmap communicates project priorities for evolving and extending the scope of the product. We encourage the community to work with us to improve SqlClient driver for these scenarios and extend it for others. |
|||
|
|||
## Released Versions |
|||
|
|||
- [Release Notes](https://github.com/dotnet/sqlclient/blob/master/release-notes/README.md) - For detailed release notes summarizing of all changes/features released. |
|||
- [GitHub Releases](https://github.com/dotnet/sqlclient/releases) - For downloading NuGet Packages and identifying driver releases with changelog notes. |
|||
|
|||
## Upcoming Ship Dates |
|||
|
|||
| Milestone | Release Date | Project Board | |
|||
|---------------------------|--------------|---------------| |
|||
| Microsoft.Data.SqlClient 1.0 (servicing) | As needed (see also [releases](https://github.com/dotnet/sqlclient/blob/master/release-notes/1.0)) | [SqlClient 1.0.0](https://github.com/dotnet/SqlClient/projects/3)| |
|||
| Microsoft.Data.SqlClient 1.1 | GA (General Availability) scheduled for November 2019 | [SqlClient 1.1.0](https://github.com/dotnet/SqlClient/projects/4)| |
|||
|
|||
> Note: Dates are calendar year (as opposed to fiscal year). |
|||
|
|||
[SqlClient Projects](https://github.com/dotnet/SqlClient/projects) are used by our development team to define roadmap of prioritized work. SqlClient Boards contain issues, pull requests, and other features, development activities that are categorized as cards. Our goal is to be transparent over priorities, work in progress and deliverables. |
|||
|
|||
Milestone information is also available for GitHub Issues and Pull Requests [dotnet/sqlclient milestones](https://github.com/dotnet/sqlclient/milestones). |
|||
|
|||
## Feedback |
|||
|
|||
The best way to give feedback is to create issues in the [dotnet/sqlclient](https://github.com/dotnet/sqlclient) repo. |
|||
|
|||
Although mostly obvious, please give us feedback that will give us insight on the following points: |
|||
|
|||
* Existing features are missing some capability or otherwise don't work well enough. |
|||
* Missing features that should be added to the product. |
|||
* Design choices for a feature that is currently in-progress. |
|||
|
|||
Some important caveats / notes: |
|||
|
|||
* It is best to give design feedback quickly for improvements that are in-development. We're unlikely to hold a feature being part of a release on late feedback. |
|||
* We are most likely to include improvements that either have a positive impact on a broad scenario or have very significant positive impact on a niche scenario. This means that we are unlikely to prioritize modest improvements to niche scenarios. |
|||
* Compatibility will almost always be given a higher priority than improvements. |
|||
@ -1,19 +0,0 @@ |
|||
<?xml version="1.0" encoding="utf-8"?> |
|||
<configuration> |
|||
<packageSources> |
|||
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" /> |
|||
<add key="MyGet" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" /> |
|||
<add key="Dotnet arcade" value="https://dotnetfeed.blob.core.windows.net/dotnet-core/index.json" /> |
|||
</packageSources> |
|||
<packageRestore> |
|||
<add key="enabled" value="False" /> |
|||
<add key="automatic" value="False" /> |
|||
</packageRestore> |
|||
<bindingRedirects> |
|||
<add key="skip" value="False" /> |
|||
</bindingRedirects> |
|||
<packageManagement> |
|||
<add key="format" value="0" /> |
|||
<add key="disabled" value="False" /> |
|||
</packageManagement> |
|||
</configuration> |
|||
Write
Preview
Loading…
Cancel
Save
Reference in new issue