When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.
- Use HLint for Haskell code suggestions (see CI)
- Use Hindent for code formatting (see CI)
- (recommended) Use extensions for your IDE/editor that integrate the tools above
- Handler - a module containing handler functions
- DTO - a module containing structures which represents request/response in API
- Middleware - a module containing middleware functions
- Service - a module containing service functions
- Mapper - a module containing mapper functions
- DAO - a module containing functions for a manipulation with data in database
- Migration - a module containing functions for running initial database migrations
- New or changed functionality must be covered by tests. Please read also the test policy.
- Pay attention to performance and potential edge cases, backend has to be robust.
- Ensure any unnecessary install or build dependencies and other generated files are removed (adjust
.gitignore
or.dockerignore
if necessary). - Explain the changes and update in the Pull Request message. If it affects our User Guide, state explicitly how it should be changed.
- Be ready to communicate about the Pull Request and make changes if required by reviewers.
- The Pull Request may be merged once it passes the review and automatic checks.
We use the standard Gitflow Workflow:
- main branch is used only for releases (and eventually hotfixes), this branch is also protected on GitHub (pull requests with review and all checks must pass)
- develop branch is used for development and as a base for following development branches of features, support stuff, and as a base for releases
- feature/* (base develop, rebase-merged back to develop when done)
- chore/* (like the feature but semantically different, not the feature but some chore, e.g., cleanup or update of Dockerfile)
- fix/* (like the feature but semantically different, not something new but fix of a non-critical bug)
- release/* (base develop, merged to main and develop when ready for release+tag)
- hotfix/* (base main, merged to main and develop)
Please note, that for tasks from our Jira, we use such
as [DSW-XXX]
identifying the project and task number.
For the release management we use (aside from the Gitflow Workflow):
- Semantic versioning
- Release Candidates - X.Y.Z-rc.N should be created if don’t expect any problems (in that case use alpha or beta), and make a walkthrough to verify its functionality according to the manuals finally - it also verifies that the documentation is up to date with the new version.
- Docker Hub image - in case of release, Docker image with the same tag will be created automatically.
- Compatibility in DSW - the matching major and minor version of DSW components must be compatible.
The changes must be captured in our User Guide.