jola5 / gtv Goto Github PK

What happens if you use strict and non-strict at the same time? At least provide some documentation about undefined behaviour. Or better make it impossible in a future release, ref #12.

Sometimes you work on projects where different branches are used for specific releases. Imagine a repository with a mature 1.9.21 release and an according branch and a brand new 2.0.3 release with according branch.

If you need to provide bugfixes and security updates for your 1.9.21 release you still need to create new minor and patch versions like 1.9.22. This is a typical use case and the git describe command works exactly as expected by returning the most git tag on this particular branch. Gtv on the other hand does not support this use case since we only update on the most recent version tag - which is 2.0.3. You can circumvent this by specifically setting a version to a specific commit with gtv set 1.9.22 abcdef987456 but the whole point of gtv is to simplify working with version tags.

Therefore, this request proposes a change so gtv works like git describe

# working on 1.x release
git checkout release_1.x.x
git describe
v1.9.21
git tag-version
2.0.3
# add a new patch to this specific release/branch
git tag-version new patch
git describe
v2.0.4
git tag-version
2.0.4
# switch to 2.x release
git checkout release_2.x.x
git describe
v2.0.3
git tag-version
2.0.4

The current implementation's behaviour is quirky, unexpected and undocumented as well.

Consider to use a proper makefile instead of the custom make.sh script. Currently target chaining is handled ok, but we lack the ability for target dependencies.

Support strict mode preventing adding multiple version tags to the same commit.

Mentioning strict mode in the online help is a bug since it is not yet implemented.

We should support adding a version to a specific commit like git tag ... COMMIT:

git tag -a v1.2 9fceb02
git tag-version new minor 9fceb02

Setup a travis build for running the tests.

Setup a github page for gtv.

Support setting some basic configuration options. Most obvious way would be to use git config itself. This supports repository specific or global settings out of the box.

See: http://craig-russell.co.uk/2011/08/24/git-tip-custom-config-parameters.html

There's shellcheck, a static analyzer for shell scripts. It looks awesome and travis integration seems so easy:

language: bash
addons:
  apt:
    sources:
    - debian-sid    # Grab ShellCheck from the Debian repo
    packages:
    - shellcheck

Addition:
Fix issues stated by shellcheck.

It should be possible to assign versions that differ in suffixes only. Currently on version comparison the suffix is ignored, hence this is not possible:

gtv set 1.22.3 --suffix=RC1
gtv show
# v1.22.3-RC1
gtv set 1.22.3
# should be v1.22.3 but is not supported right now

A nice idea about combining golang with shell can be found here: https://jvns.ca/blog/2017/07/30/a-couple-useful-ideas-from-google/ --> write shell scripts in golang.

Installation instructions.

• How to add to executable path?
• How to add as custom git command?

The gtv source code is not too consistent. And install.sh and mak.sh differ even more.

To improve code quality we should abide a proper coding style guide. Preferably something widely used. A favorite is https://google.github.io/styleguide/shell.xml.

If you need to assign a version to previous commits (ref. #9) the version may correctly need to be lower than the most current version. Current implementation enforces all new versions must be strictly increasing.

This feature should provide a command line option --force to support this kind of need.

Nice looking asciinema instead of the online help copy in README's Basic Usage.

Use https://github.com/mvdan/sh, a "shell parser, formatter and interpreter (POSIX/Bash/mksh)" instead of bash -n for syntax checks as mentioned here.

Although the historical reason for the name git-tag-version coming from a version assigned through a tag is understandable a more meaningful naming like git-semantic-versioning would be more precise.

Things to change

• shorthand gsv
• full name git semantic versioning
• git alias git-semver -> git semver new patch

Basic tests. Probably system tests of the Basic Usage command flow.

Since there was a recent issue where gtv was relying on a specific git feature only present in a more recent git version (#15, #21) we should do the following:

1. State the supported git version(s) in the docs
2. Test against multiple git versions on Travis

Currently the parameter naming is quite a bit confusing and should be streamlined for a future release:

• strict-mode/non-strict for adding tags to the same commit vs. a strictly increasing version number scheme
• adding a version number that is not strictly increasing with force , ref #11

Create a code coverage report for tests to improve test coverage in the future.

Currently the installation directory is hard coded. Users should have the freedom to install to any directory.