@@ -10,4 +10,103 @@ provided by the bot. You will only need to do this once across all repos using o
1010
1111This project has adopted the [ Microsoft Open Source Code of Conduct] ( https://opensource.microsoft.com/codeofconduct/ ) .
1212For more information see the [ Code of Conduct FAQ] ( https://opensource.microsoft.com/codeofconduct/faq/ ) or
13- contact [ opencode@microsoft.com ] ( mailto:opencode@microsoft.com ) with any additional questions or comments.
13+ contact [ opencode@microsoft.com ] ( mailto:opencode@microsoft.com ) with any additional questions or comments.
14+
15+ ## Development Guidelines
16+
17+ ### Versioning
18+
19+ This project follows open-source industry standard [ Semantic Versioning] ( https://semver.org/ ) :
20+
21+ ** Version Format:** ` MAJOR.MINOR.PATCH ` (e.g., ` 1.2.3 ` )
22+
23+ ** When to bump:**
24+ - ** MAJOR** (e.g., 1.0.0 → 2.0.0): Breaking changes that require users to update their code
25+ - Removing public methods, classes, or modules
26+ - Changing method signatures (parameters, return types)
27+ - Changing default behavior that breaks existing code
28+ - Dropping Python version support
29+
30+ - ** MINOR** (e.g., 1.0.0 → 1.1.0): New features that are backwards-compatible
31+ - Adding new public methods or classes
32+ - Adding optional parameters (with defaults)
33+ - New features that don't break existing code
34+ - Adding Python version support
35+
36+ - ** PATCH** (e.g., 1.0.0 → 1.0.1): Bug fixes that are backwards-compatible
37+ - Fixing bugs without changing the API
38+ - Documentation updates
39+ - Security fixes (non-breaking)
40+ - Internal refactoring
41+
42+ ### Changelog
43+
44+ We maintain a [ CHANGELOG.md] ( CHANGELOG.md ) following the [ Keep a Changelog] ( https://keepachangelog.com/ ) format.
45+
46+ ** For Contributors:** You don't need to update the changelog with your PRs. Maintainers will update it at release time.
47+
48+ ** For Maintainers (Release Process):**
49+
50+ Before each release, review merged PRs and update the changelog with:
51+
52+ ** What to include:**
53+ - ✅ New features (→ ** Added** )
54+ - ✅ Changes to existing functionality (→ ** Changed** )
55+ - ✅ Soon-to-be removed features (→ ** Deprecated** )
56+ - ✅ Removed features (→ ** Removed** )
57+ - ✅ Bug fixes (→ ** Fixed** )
58+ - ✅ Security fixes (→ ** Security** )
59+ - ❌ Internal refactoring (unless it affects performance/behavior)
60+ - ❌ Test-only changes
61+ - ❌ CI/CD changes
62+ - ❌ Documentation-only updates
63+
64+ ** Process:**
65+ 1 . Review all PRs merged since last release
66+ 2 . Add user-facing changes to CHANGELOG.md under appropriate categories
67+ 3 . Include PR numbers for reference (e.g., ` (#123) ` )
68+ 4 . Focus on ** why it matters to users** , not implementation details
69+
70+ ** Adding version links to CHANGELOG.md:**
71+
72+ After creating tags, add version comparison links at the bottom of CHANGELOG.md:
73+
74+ ``` markdown
75+ [ 0.1.0b3 ] : https://github.com/microsoft/PowerPlatform-DataverseClient-Python/compare/v0.1.0b2...v0.1.0b3
76+ [ 0.1.0b2 ] : https://github.com/microsoft/PowerPlatform-DataverseClient-Python/compare/v0.1.0b1...v0.1.0b2
77+ [ 0.1.0b1 ] : https://github.com/microsoft/PowerPlatform-DataverseClient-Python/releases/tag/v0.1.0b1
78+ ```
79+
80+ ### Git Tags and Releases
81+
82+ We use git tags to mark release points and GitHub Releases for announcements.
83+
84+ ** Creating Git Tags:**
85+
86+ Git tags should be created for every release published to PyPI:
87+
88+ ``` bash
89+ # Create annotated tag for version X.Y.Z
90+ git tag -a vX.Y.Z -m " Release vX.Y.Z"
91+
92+ # Push tag to remote
93+ git push origin --tags
94+ ```
95+
96+ ** GitHub Releases:**
97+
98+ After publishing to PyPI, create a GitHub Release based on CHANGELOG.md
99+
100+ ** Release notes format:**
101+
102+ ``` markdown
103+ Brief summary of the release
104+
105+ ### Added
106+ - Feature 1 (#123 )
107+ - Feature 2 (#124 )
108+
109+ ### Fixed
110+ - Bug fix 1 (#125 )
111+ - Bug fix 2 (#126 )
112+ ```
0 commit comments