arnaud-deprez/gsemver

gsemver uses git commit convention to automate the generation of your next semver version

gsemver's Issues

Add major-pattern and minor-pattern parameter

Is your feature request related to a problem? Please describe.

Using the CLI, it's currently not possible to override the regex pattern for major and minor commit match.

Describe the solution you'd like

We should allow this via command line parameters

Additional context

This is a subtask of #4

Support Main CI tools out of the box

Is your feature request related to a problem? Please describe.

Given most CI tools do git fetch in detached mode, gsemver cannot directly inspect what is the current branch.
Instead you can set an environment variable GIT_BRANCH to let gsemver knows which branch it should use to match against a bumpStrategy.

Describe the solution you'd like

As most CI tools provides the current branch context in some environment variables, it is possible to determine in which CI tool the build is running and then get the correct branch information from env variables.

Out of my head CI tools to support:

• github actions
• gitlab ci
• bitbucket
• jenkins
• azure pipeline
• aws codebuild
• google cloud build
• Other CI tools ?

GIT_BRANCH should still be used as a fallback solution for the not yet supported CI tools.

Add coverage testing report

Is your feature request related to a problem? Please describe.

The quality of the project is not really measurable.

Describe the solution you'd like

We should add testing coverage report to improve the quality.

Additional context

https://codecov.io seems to be widely used.

Allow usage of "empty" pre-release

Is your feature request related to a problem? Please describe.

Currently we can only pre-release with a name (alpha, beta, whatever...).

Describe the solution you'd like

It should be possible to use unqualified pre-release like 1.0.0-0, 1.0.0-1, ...

Additional context

This is a sub-task of #4

Add integration example with build tools

Describe the solution you'd like

We should some examples on how to integrate gsemver with well known build tools such as:

• maven
• gradle
• sbt
• npm/yarn
• bazel

Any other suggestion is welcome.

Describe alternatives you've considered

Alternatively it might be good to develop some plugin for these build tools.

Additional context

For each of these examples, we should create an issue and refer to this epic and then check the box when the implementation is merged.

Support for `!` notation for breaking change

Is your feature request related to a problem? Please describe.

Conventional commits supports ! to draw attention to breaking change.

Eg:

feat!: send an email to the customer when a product is shipped
# or
feat(api)!: send an email to the customer when a product is shipped

Describe the solution you'd like

• gsemver should bump MAJOR when it finds such a commit

Additional context

• make sure git-chglog supports this notation too for gsemver release itself

Add optional verbosity

Is your feature request related to a problem? Please describe.

Currently verbose and log-level options are not used because we don't log anything.
So when gsemver fails, it can be hard to know why and where.

Describe the solution you'd like

We should add optional verbose logs at each steps to give some insights in case of failure

Add integration tests with real git repository

Is your request related to a problem? Please describe.

In order to fully validate gsemver we should setup some integration tests with a real git repository

Describe alternatives you've considered

Some unit tests exist but they don't allow to validate complex scenario with history.

Generate release notes based on commits log

Is your feature request related to a problem? Please describe.

Before publish the first release, we should generate release notes for it based on our conventional commits history.

Additional context

Some tools to consider:

• https://github.com/git-chglog/git-chglog
• https://github.com/Songmu/ghch
• https://github.com/buchanae/github-release-notes

Add command to initialise custom configuration

Is your feature request related to a problem? Please describe.

Once #20 is done, we need a simple way to bootstrap a custom configuration.

Describe the solution you'd like

Add command to initialise custom configuration file by asking first some question to the end user.

Describe alternatives you've considered

A very simple approach would be able to view the current configuration with a command that prints the current file on the console.
Then we can just redirect the standard output to a file so that we can manually customise it.

Note that it is not incompatible with this solution and might be easier to it first.

As a user I would like to not bump version on some commit patterns

Is your feature request related to a problem? Please describe.

There can be some commits that should not produce a new release - and thus bump to a new version - in some scenario, like for example if you fix a type in a README, it might not make sense to create a release.

Describe the solution you'd like

The goal is to give the ability to the user to not bump version on some commit that match a pattern.

Questions

• What should be the default behaviour here ?

Add automatic support for release branches

Is your feature request related to a problem? Please describe.

In traditional development workflow, we have release branches from where we release our application and development branches (feature, bug, ...) where the work is on going.

Describe the solution you'd like

The gsemver bump [auto] should automatically detects if it's a release branch or "under work" branch and use build metadata in the later.

Describe alternatives you've considered

This initial implementation should consider master and release/* branches as release branches and the rest as "under work" branches.
In future version, it would be nice if this could be configurable.

how to bump version with submodule path when publishing-a-release with dir

Describe the bug

i have a submule for separating rpc client module for other team, which is under th help of submodule tag.

u can refer to this: https://github.com/golang/go/wiki/Modules#publishing-a-release

To Reproduce

Expected behavior

hope to bump patch successfully.

Screenshots

Version:

• output of git version [e.g. 2.22.0]
• gsemver version ?

(⎈|test-ctx:ticket-system)➜  ticket_system git:(feature/update-ticket-msg) gsemver version   
version.BuildInfo{Version:"0.1.0", GitCommit:"", GitTreeState:"", BuildDate:"", GoVersion:"go1.17", Compiler:"gc", Platform:"darwin/arm64"}

Use configuration files

Is your feature request related to a problem? Please describe.

From gsemver 0.3.x, it will be possible to use different bump strategy per branch.
While it is possible to configure via command line parameter and some json, it's not convenient.

Describe the solution you'd like

It should be possible to store configuration in a file and use it when bumping the version.

Ideally, it should also be possible to use one global file (user file), and specific file stored in some default location or given location via a parameter where the later take precedence over the former in this list.

Moreover, command line arguments should always take precedence over file configuration.

Additional context

This is a sub-task of #4

Adapt version bump rules

Is your feature request related to a problem? Please describe.

Based on Angular commit convention:

• build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
• ci: Changes to our CI configuration files and scripts (examples: CircleCi, SauceLabs)
• docs: Documentation only changes
• feat: A new feature
• fix: A bug fix
• perf: A code change that improves performance
• refactor: A code change that neither fixes a bug nor adds a feature
• test: Adding missing tests or correcting existing tests

Describe the solution you'd like

Therefore, for the given commit types:

• feat, chore, build, ci, refactor, perf -> gsemver should bump MINOR
• fix, docs, test -> gsemver should bump PATCH

Match tag with or without `v` prefix

Is your feature request related to a problem? Please describe.

Currently gsemver only match tags prefixed with v.
Some project does not use this standard.

Describe the solution you'd like

gsemver should match tag with and without v prefix

Additional context

This is a sub-task of #4

Try github actions

Describe the solution you'd like

It would be nice to try github actions to see if it better integrates with github.

Additional context

We may want to run github actions in parallel with travis for a few times before choosing between travis and github actions

Allow to use different bump strategy per branch(es) in auto mode

Is your feature request related to a problem? Please describe.

When project starts getting mature, it's common to use a branch for a pre-release which should later become a release when it is fully merged into master.

Describe the solution you'd like

It should be possible to define different bump strategy per branch or set of branches.

Additional context

This is a sub-task of #4

Use go template for build-metadata and pre-release

Is your feature request related to a problem? Please describe.

For build-metadata we might want to use some information like the current branch, the number of commits since the latest version, etc.
We might want to the same for pre-release even if it's less common.

Describe the solution you'd like

Using go template with a context containing all the necessary information should give the needed flexibility.

Additional context

This is a sub-task of #4

Make gsemver bump auto more configurable

Is your feature request related to a problem? Please describe.

Currently gsemver bump [auto] uses:

• conventional commits convention to generate the next version.
• look for tags with v prefix to find the latest version.
• generate version with build metadata on non release branches

Describe the solution you'd like

A lot of project do not use these conventions but others such as:

• git flow kind of convention: eg. a fix should be done in bug/* branch, a feature in feature/*, a breaking change in major/* or so. While it's not possible in git to retrieve the original branch, you can leverage a merge commit that contains the name of that branch and configure regular expression to match it.
• some projects use different prefix or no prefix at all for their tags
• some projects prefer to use pre-release on non release branch such as most of the maven project with their -SNAPSHOT version.

Additional context

We may want to leverage go template to define the version format in non release branches for example to reuse the current branch name, the commit id, the number of commits from the latest tag, etc.

So this feature should probably be split into smaller issues.

Tasks

• Allow to match tag with or without v prefix #16
• Allow to use different bump strategy per branch(es) in auto mode #17
• Use go template for build-metadata and pre-release #18
• Add major-regex and minor-regex parameter #23
• Allow usage of "empty" pre-release #25
• Use configuration files #20

gsemver bump patch does not fetch the original tag firstly

Describe the bug

when i use A feature branch, the patch has already been up to 1.0.100.But when changing the B branch , the patch version will be 0.0.1.

➜  ticket_system git:(feature/jwt) gsemver bump patch
0.0.2%                                                                                                                                                                                                                                  ➜  ticket_system git:(feature/jwt) git checkout feature/ticket_system
Switched to branch 'feature/ticket_system'
Your branch is up to date with 'origin/feature/ticket_system'.
➜  ticket_system git:(feature/ticket_system) gsemver bump patch
1.0.343%  

@arnaud-deprez hope to get yr early reply

Add version sub-command

Is your feature request related to a problem? Please describe.

Add a version sub-command to known what version of the tool we have.

Describe the solution you'd like

gsemver version output the version of gsemver

Add command to view current configuration

Is your feature request related to a problem? Please describe.

This is to complement #27

Describe the solution you'd like

Add a command to view the current merged configuration with a command that prints the current file on the console.