[FEATURE] Allow The User To Configure Which Conventional Commit Keywords Cause Which Kind Of Version Bump

by ADMIN 106 views

Introduction

Conventional commits have become a widely adopted standard for managing commit messages in software development. By following a specific format, developers can easily identify the type of change made in a commit, making it easier to track and manage the project's history. However, the default behavior of conventional commits, which only considers certain keywords for version bumps, may not be suitable for all projects. In this article, we will explore a feature request that allows users to configure which conventional commit keywords cause which kind of version bump.

Motivation

At the moment, only the keywords fix, feat, and BREAKING CHANGE will cause a version bump. This default behavior is based on the conventional commits specification, which recommends using these keywords to indicate different types of changes. However, users might want to customize this behavior to suit their specific needs. For example, a project might use custom keywords to indicate dependency updates, such as deps. This is where the proposed solution comes in – allowing users to configure which conventional commit keywords cause which kind of version bump.

Proposed Solution

To achieve this customization, we propose creating a structure that represents a mapping between keywords and version bumps. This mapping can be stored in a YAML file, which can be configured by the user. If no file exists, the default behavior should be used. This approach provides a flexible and customizable way to manage version bumps, allowing users to tailor the behavior to their specific project needs.

Configurable YAML File

The YAML file will contain a mapping between keywords and version bumps. For example:

version-bumps:
  - keyword: fix
    version-bump: patch
  - keyword: feat
    version-bump: minor
  - keyword: BREAKING CHANGE
    version-bump: major
  - keyword: deps
    version-bump: patch

In this example, the fix keyword will cause a patch version bump, while the feat keyword will cause a minor version bump. The BREAKING CHANGE keyword will still cause a major version bump, and the custom deps keyword will cause a patch version bump.

Open Question: Commit Message Body Representation

One open question is whether the commit message body should be represented differently from the keyword. In the conventional commits specification, the commit message body is not considered when determining the version bump. However, some users might want to include additional information in the commit message body that could affect the version bump. For example, a commit message might include a description of the change, along with the keyword. In this case, the commit message body could be represented as a separate field in the YAML file, allowing users to customize the behavior.

Implementation

To implement this feature, we will need to create a new structure to represent the mapping between keywords and version bumps. This structure will be stored in a YAML file, which can be configured by the user. We will also need to update the conventional commits parser to read the YAML file and apply the custom mapping.

Benefits

The benefits of this feature are numerous. By allowing users to configure which conventional commit keywords cause which kind of version bump, we can provide a more flexible and customizable approach to managing version bumps. This will enable users to tailor the behavior to their specific project needs, making it easier to manage version bumps and ensure that the project's history is accurate and up-to-date.

Conclusion

In conclusion, the proposed feature allows users to configure which conventional commit keywords cause which kind of version bump. This customizable approach to managing version bumps will provide a more flexible and tailored solution for users, making it easier to manage version bumps and ensure that the project's history is accurate and up-to-date. By implementing this feature, we can provide a more robust and user-friendly conventional commits experience.

Future Work

Future work on this feature could include:

  • Adding support for multiple YAML files: Currently, the YAML file is stored in a single location. In the future, we could add support for multiple YAML files, allowing users to configure different mappings for different projects or environments.
  • Integrating with other tools: We could integrate this feature with other tools, such as continuous integration/continuous deployment (CI/CD) pipelines, to provide a more seamless experience for users.
  • Providing a user interface for configuration: We could provide a user interface for configuring the YAML file, making it easier for users to customize the behavior without having to edit the file manually.

Q: What is the purpose of configurable conventional commits?

A: The purpose of configurable conventional commits is to allow users to customize the behavior of conventional commits, specifically which keywords cause which kind of version bump. This provides a more flexible and tailored solution for users, making it easier to manage version bumps and ensure that the project's history is accurate and up-to-date.

Q: Why is the default behavior of conventional commits not suitable for all projects?

A: The default behavior of conventional commits, which only considers certain keywords for version bumps, may not be suitable for all projects. For example, a project might use custom keywords to indicate dependency updates, such as deps. This is where the proposed solution comes in – allowing users to configure which conventional commit keywords cause which kind of version bump.

Q: How does the configurable YAML file work?

A: The configurable YAML file contains a mapping between keywords and version bumps. For example:

version-bumps:
  - keyword: fix
    version-bump: patch
  - keyword: feat
    version-bump: minor
  - keyword: BREAKING CHANGE
    version-bump: major
  - keyword: deps
    version-bump: patch

In this example, the fix keyword will cause a patch version bump, while the feat keyword will cause a minor version bump. The BREAKING CHANGE keyword will still cause a major version bump, and the custom deps keyword will cause a patch version bump.

Q: Can I include additional information in the commit message body that affects the version bump?

A: Yes, you can include additional information in the commit message body that affects the version bump. For example, a commit message might include a description of the change, along with the keyword. In this case, the commit message body could be represented as a separate field in the YAML file, allowing users to customize the behavior.

Q: How do I configure the YAML file?

A: You can configure the YAML file by editing it manually or using a user interface provided by the tool. The YAML file should be stored in a location that is accessible to the tool, and the tool should be configured to read the YAML file and apply the custom mapping.

Q: What are the benefits of configurable conventional commits?

A: The benefits of configurable conventional commits are numerous. By allowing users to configure which conventional commit keywords cause which kind of version bump, we can provide a more flexible and customizable approach to managing version bumps. This will enable users to tailor the behavior to their specific project needs, making it easier to manage version bumps and ensure that the project's history is accurate and up-to-date.

Q: What are the future work items for configurable conventional commits?

A: Future work on configurable conventional commits could include:

  • Adding support for multiple YAML files: Currently, the YAML file is stored in a single location. In the future, we could add support for multiple YAML files, allowing users to configure different mappings for different projects or environments.
  • Integrating other tools: We could integrate this feature with other tools, such as continuous integration/continuous deployment (CI/CD) pipelines, to provide a more seamless experience for users.
  • Providing a user interface for configuration: We could provide a user interface for configuring the YAML file, making it easier for users to customize the behavior without having to edit the file manually.

Q: How can I get started with configurable conventional commits?

A: To get started with configurable conventional commits, you can follow these steps:

  1. Understand the conventional commits specification: Familiarize yourself with the conventional commits specification and how it works.
  2. Configure the YAML file: Edit the YAML file to configure the mapping between keywords and version bumps.
  3. Integrate with your toolchain: Integrate the configurable conventional commits feature with your toolchain, such as your CI/CD pipeline.
  4. Test and validate: Test and validate the feature to ensure it works as expected.

By following these steps, you can get started with configurable conventional commits and take advantage of its benefits.