Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
93 lines (61 loc) · 3.51 KB

CONTRIBUTING.md

File metadata and controls

93 lines (61 loc) · 3.51 KB
Raw

Contributing to springboot-framework

Welcome to springboot-framework ! This document is a guideline about how to contribute to springboot-framework. If you find something incorrect or missing, please leave comments / suggestions.

Before you get started

Code of Conduct

Please make sure to read and observe our Code of Conduct.

Setting up your development environment

You should have JDK 17 or later installed in your system.

The project ships with the Maven Wrapper, so there is no need to install Maven separately.

# Full build
./mvnw clean install

# Run the tests only (the same command CI uses)
./mvnw clean test -P travis

Contributing

We are always very happy to have contributions, whether for typo fix, bug fix or big new features. Please do not ever hesitate to ask a question or send a pull request.

We strongly value documentation and integration with other projects. We are very glad to accept improvements for these aspects.

GitHub workflow

Development mainly happens on version branches (e.g. 17.3.x, 8.2.x) and on the dev branch, which is an unstable branch. The main branch stays stable, and CI runs on pushes and pull requests targeting main, dev, 2.x, 8.2.x and 17.3.x.

The project version (e.g. 17.3.0-SNAPSHOT, where 17 is the JDK version, 3 is the Spring Boot major version and the last number is the patch version) is managed with the Maven ${revision} CI-Friendly mechanism, so no pom.xml needs to be modified during development or for a release.

Here are the workflow for contributors:

  1. Fork to your own
  2. Clone fork to local repository
  3. Create a new branch and work on it
  4. Keep your branch in sync
  5. Commit your changes (make sure your commit message concise)
  6. Push your commits to your forked repository
  7. Create a pull request

Please follow the pull request template. Please make sure the PR has a corresponding issue.

After creating a PR, one or more reviewers will be assigned to the pull request. The reviewers will review the code.

Before merging a PR, squash any fix review feedback, typo, merged, and rebased sorts of commits. The final commit message should be clear and concise.

Open an issue / PR

We use GitHub Issues and Pull Requests for trackers.

If you find a typo in document, find a bug in code, or want new features, or want to give suggestions, you can open an issue on GitHub to report it. Please follow the guideline message in the issue template.

If you want to contribute, please follow the contribution workflow and create a new pull request. If your PR contains large changes, e.g. component refactor or new components, please write detailed documents about its design and usage.

Note that a single PR should not be too large. If heavy changes are required, it's better to separate the changes to a few individual PRs.

Code review

All code should be well reviewed by one or more committers. Some principles:

  • Readability: Important code should be well-documented. Comply with our code style.
  • Elegance: New functions, classes or components should be well designed.
  • Testability: Important code should be well-tested (high unit test coverage).

Community

Contact us

Mailing list

If you have any questions or advice, please contact wangliang@codingapi.com.