markchalloner / git-semver Goto Github PK

As mentioned in #12

Like git tag 0.2.1 -m message

If I generate a bunch of pre-release tags and then create a release tag, the git semver get is not able to fetch the correct last generated tag. e.g.

test env preparation

mkdir test && cd test && git init
echo 'test' > test
git add test
git commit -m "test"

test

git tag 1.0.0
git tag 1.0.1-alpha
git tag 1.0.1-beta
git tag 1.0.1-rc
git tag 1.0.1

git semver get

I'd expect to see 1.0.1 as a result but I'm getting 1.0.1-rc which IMHO is not correct.

Hi,

Just wondering if anyone is working on

(a) a system that automagically works out if a tag is MAJOR / MINOR / PATCH based on the commit message

(b) adding git push --tags to the end of the script

Let me know where we can help - if not.

Thank you

Nicolaas
PS awesome module

date on OSX (at least on El Capitan) uses -d to set the kernel's value for daylight saving time.

date -d "2015-11-13" "+%s"

Should be changed to:

date -j -f "%Y-%m-%d" "2015-11-13" "+%s"

I was attempting to check the tag: git semver minor --dryrun however I forget to add the --dryrun and it incremented my minor version. How do I roll the tag back? I did not yet push the tags using git push -tags, this is all still local to my machine.

Thanks!

Hello,

First, thanks for the share.

With the resolution of #9 with d16599d, I have an error due to -j option (not exists in Jessie) :

 ~  dev  git-semver   master  ✔  00:19:41  130  git semver get
date : option invalide -- 'j'
Saisissez « date --help » pour plus d'informations.
date : option invalide -- 'j'
Saisissez « date --help » pour plus d'informations.
/usr/local/bin/git-semver: ligne 185 : [: -86400 : opérateur unaire attendu
2.0.2

Perhaps it should be useful to add a ondition to choice the proper date syntax, based on date version or OS family/distribution ?

For information :

• date version on Jessie : 'date (GNU coreutils) 8.23'
• I've disable updates to avoid the problem :)

README keeps saying "git-semvar" but package is named "git-semver", which of the two is it?

You cannot have both a local config file and a plugins directory in the same repo.

This line above checks for a .git-semver file for the config, while the code below looks for the .git-semver/plugins directory:

Maybe I'm missing something, but you can't have a file be a folder.

Tags should be named v1.2.3, etc. This is the tagging scheme used by Git and the kernel itself. It's best when everyone uses the same convention.

I've a project which right now is at version v0.28.13. Using git semver patch creates the version 0.1.0:

The expected result would be to create the version v0.28.14.

Same result using minor:

.

In this case, the expected result would be v0.29.0.

Note that I've also created an issue because the prefix setting is being ignored (see #23).

Is it possible to bump to a pre-release? Something like 1.0.0-beta.2 as explained sermver 2.0.0.

Is it possible to automatically increment patch versions per commit?

Using the example plugin without modification, the "current version" argument doesn't contain VERSION_PREFIX config setting.

See output:

$ git semver minor

User plugin "example.sh":

  New version: v0.2.0
  Current version: 0.1.0
  ...
v0.2.0

Notice how "current version" is "0.1.0" while new version is "v0.2.0" (with v)

This seems to be because the version-do method is being called without the VERSON_PREFIX for $version in version-major, version-minor, and version-patch :

I can make a PR.

Despite I've configured the version prefix as stated in the readme, it does not add the prefix to versions.

Thanks to this plugin for git.

Before I try this plugin, I have my repos trying to do semver manually. Then I got this plugin, I wish it to do the semver job based on the existed versions. So the new minor version should be 0.2.1, right?

On more thing, how about the -m message option support? just like git tag 0.2.1 -m message .

Hi everyone,

First of all, thanks for this amazing tool. Believe it or not, I just found this last week, after some heavy googling, and I can't understand how it never appeared in previous searches.

Anyway, getting to the issue.

I usually manage two extra set of tags on the projects I use semver on: For a 1.5.1 release for example, I would have a 1.5.1 tag, a 1.5 and a 1 tag pointing to the same commit. And, if I happen to make a 1.5.2 release, I would delete and recreate the 1.5 and 1 tags, pointing them to the same commit 1.5.2 is on.

This is specially useful for maintaining multiple versions in things like rest APIs, so that you can build your code tagging, for example, the 1.5 series, and always get the latest fixes.

So I was wandering, would some code like this be of any interest to you, to add that functionality?

Again, thanks for this tool
Fernando

The XDG Base Directory Specification is a set of standards for the locations of config files and similar things. (It’s designed for Linux, but even though I’m on OS X I use it to organize my dotfiles and keep my home directory tidy.)

For this project, you would just have to check for configuration in ~/.config/.git-semver/config first. If it exists, use it. Otherwise, fall back to ~/.git-semver/config as normal.

Hi!

Thank you for this plugin it's a nifty little helper. Just wanted to point out that it doesn't handle several digits though. I've just been using it for building a new product right now and until deploying the first MVP we're just using v0.0.x and up to x=13 now, but since we reached x=10 it just gives fatal error v0.0.10 every time you call git semver patch, so we have to do it manually.

I'm assuming it's not too hard if you know bash well, I was trying to look at the code to see if I could do it myself but not a bash guru so it wasn't obvious to me anyway.

This issue closes #23 & #24, as those issues are fixed in master.

The current installation process described in the readme installs an old version with some issues on it.

I guess that just creating a new tag would fix this.