[INFRA] Use annotated tags for releases

[yarikoptic]

Streamlines use of git describe etc

$> git tag                    
v.1.1.2
v1.1.2
v1.2.0

# 1.1.2 is proper annotated:
$> git describe e21e619       
v1.1.2-227-ge21e619

# but 1.2.0 (github does mis-service in producing those while doing releases on github web ui)
# so --tags is needed to get proper one for 1.2.0
$> git describe --tags e21e619
v1.2.0-67-ge21e619

So ATM older tag is an annotated one while the latest one is not.
I guess we fell into the trap of github where it doesn't create annotated tags when releases made from the web UI.

[franklin-feingold]

Thank you for raising this! If I am interpreting correctly - the tags created due to a release (via github web) are not annotated to the release because it is done via web ui? To fix this and have annotated tags for releases, how may you recommend the release protocol be altered to enable this?

[yarikoptic]

I have searched again and I think github still doesn't allow anyhow to create annotated tags via web ui. So the only way I know, and possible way is to

• create them locally (just annotated or even signed) via git tag -a <RELEASE> [<COMMIT>] or git tag -s <RELEASE> [<COMMIT>] (for signed tag).
  • I also typically add changelog for the release within tag description, so it is right there for me when I want to see the release details. The problem though that markdown ## section annotations are treated by git as comments
• push to github git push origin <RELEASE> (git push --tags origin might be other tags present locally which might be undesirable)
• and only then go to releases web ui and make the release from that tag ("Edit" existing tag, "Publish the Release" or alike -- whatever green button it is in that interface).

NB there is a "rogue" tag v.1.1.2, (the same as v1.1.2), I would recommend git push origin :v.1.1.2 ;-)

[effigies]

Bad tag removed and release updated to the correct v1.1.2 tag.

[effigies]

@yarikoptic Should I create an annotated tag for v1.1.2?

[yarikoptic]

I am confused...

Bad tag removed and release updated to the correct v1.1.2 tag.
@yarikoptic Should I create an annotated tag for v1.1.2?

are you talking about v.1.1.2 (when saying "removed") ? but there was one annotated one already

$> git show v1.1.2
tag v1.1.2
Tagger: Chris Gorgolewski <krzysztof.gorgolewski@gmail.com>
Date:   Sun Jan 13 12:59:43 2019 -0500

same as v.1.1.2

what is missing is annotated for v1.2.0

$> git show v1.2.0
commit dbdf32e7790eb7155bdbc57a8ff93f9ba2b9ebde (tag: v1.2.0)
Merge: efd2a97 07d466e
Author: Chris Gorgolewski <krzysztof.gorgolewski@gmail.com>
Date:   Mon Mar 4 08:18:58 2019 -0800

    Merge pull request #161 from chrisfilo/rel/1.2.0
    
    REL: v1.2.0

and for that one - yes, probably best to remove, create annotated, force push

[effigies]

Ah, yes. I removed v.1.1.2. I missed that 1.2.0 was the non-annotated one. Okay.

[effigies]

Updated the tag. Looks like GitHub was okay with:

git checkout v1.2.0
git tag -f -a -m v1.2.0 v1.2.0
git push -f upstream v1.2.0

Running

$ git clone https://github.com/bids-standard/bids-specification.git
$ git -C bids-specification describe 
v1.2.0-83-g0a932f2

[sappelhoff]

closed through #235