This project is governed by a Code of Conduct.
Before writing any code, please open an issue, or let's have a discussion about any features or ideas that you may have.
No-nos! Saying this upfront, please do not upgrade any NuGet dependencies and please do not modify any licensing information, e.g. do not update the copyright year. I have strong opinions on how I like these to be managed.
Okay, once you have the feature or idea is fleshed out, it's hacking time!
- Fork it
- Branch it
- Hack it
- Save it
- Commit it
- Push it
- Pull-request it
The above is respectively taken from the Clearwater framework repository.
Kudos to Jamie Gaskins for framing the guidelines so succinctly.
Given there are now multiple versions of Contentment that support multiple versions of Umbraco, please make note of the branching structure.
- The main
develop
branch is where the latest work happens. This defaults to the most recent version of Contentment, (at the time of writing, this is v3.x). - The
dev/v1.x
branch is for Contentment v1.4.x patch releases, this targets Umbraco v8.6.1. - The
dev/v2.x
branch is for Contentment v2.2.x patch releases, this targets Umbraco v8.14.0. - The
dev/v3.x
branch is for Contentment v3.4.x patch releases, this targets both Umbraco v8.17.0 and v9.0.0. - The
dev/v4.x
branch is for Contentment v4.x (current) releases, this targets Umbraco v8.17.0, v9.5.0 and v10.0.0. - The
dev/v5.x
branch is for Contentment v5.x (next) releases, this targets Umbraco v10.0.0.
I've been thinking a lot about Jeff Geerling's post "Why I close PRs (OSS project maintainer notes)" lately. If you do submit a PR and feel that I'm closing down the conversation, this is most likely the rationale behind it.