Development Cycle

The below will provide a guide on how you should develop for this plugin to have your code reviewed and accepted.

Setup Repository

  • Fork the repo in github

  • Clone the project to your development machine (or follow the DevContainer instructions)

git clone https://github.com/your-username/atomic-calendar-revive.git

Create Topic Branch

You should always work on a new topic branch for each feature / bug you are working on. Also you must ensure that you have pulled the latest version from upstream see below.

Start by setting up an upstream remote, this will be used to pull the latest version from the main repository:

git remote add upstream https://github.com/totaldebug/atomic-calendar-revive

Checkout the beta branch and pull the latest upstream version:

git checkout beta
git fetch upstream
git merge upstream/beta
git push

Your fork should now be in sync with the main totaldebug repository.

Install Dependencies

From the cloned repository, run the command to install the requirements:

yarn install

Note

If you are using VSCode devcontainer this happens as part of the post steps.

Make changes

You are now ready to make changes to the code, all source code is in the src directory there should be no need to change any other files.

Testing

There are no automated tests for this project, however it is expected that any development work is tested against a HA Server with both CalDav and Google Calendar attached, this ensures no adverse impact is added with the feature or bugfix.

To create the card run the command yarn run build this output into the dist folder, this can then be uploaded to HA for testing.

Versioning

You dont need to worry about versioning, the release process takes care of that for you!

But in case you are curious this project follows Semantic Versioning

MAJOR.MINOR.PATCH

In the context of semantic versioning, the following should apply:

  • Major - A breaking change that requires user intervention, or a change to a default value.

  • Minor - A change that does not require intervention, or adds additional functionality in a backwards compatible manner.

  • Patch - A change that resolves a specific bug.

All changes are tracked in the release notes

Commit Changes

Once you are happy with the changes, these can be committed (I recommend using commitizen):

git add .
git cz

Then follow the prompts and select the relevant options. If this resolves a specific issue, be sure to enter the issue number when prompted.

git add .
git commit -v -m "feat: Added new feature #100"

Note

Commit messages MUST follow conventional commits this ensures clear commit messages within the repository. Without this your change will be rejected as it is required for release.

Breaking changes are detected with ! e.g. feat!: my breaking change

Submit Pull Request

Once development & testing are completed a pull request can be created to the beta branch.

A member of the team will review the request, test and merge if appropriate.