Git tags

[Austin Wright]

I noticed not all the releases are tagged in the Git repositories, particularly GitHub which seems to be the canonical one. Having all the tags are important for being able to do things like `git blame` and `git describe`, and correlating past targz releases to a particular Git commit.

Presently my issue is about commit 2fca297b3fb82201f746c3e417f7764cad97abf0 on GitHub, since other people refer to commit v0.9.9, which is not tagged. However, anyone looking for tags on any repository should come across the same problem.

I'd be happy to do the tagging. They would be simple tags, I don't know if you'd prefer to standard tag objects with a developer's name on them. Here's the full list to loop through with e.g. git tag -a -m "Tag $v" v$v $commit

v0.0.0 5023483a2f67acd154f6fdf2760a28dc952308fc

v0.7.0 19ff003a2197f8eb06b74775d2c213f1ac3c5a0f

v0.8.0 faf0e5da9eada25a8ae49b1e5ef08e8ad6f741f1

v0.8.1 9135798d2e9bb7664c7f329ab68c6e3bfcd1ee43

v0.8.2 607186ea533b76b351d74bb2e618cfd2e79afe5c

v0.9.0 a893d464d4c3f42bdf23da7fa081f2620cb76990

v0.9.1 df2de3a40a0430b50daac6808215fb9e94b3833b

v0.9.2 2a5e9a5b8f0115bcf37c5bd16801a76e8f8a9c95

v0.9.3 4b82dd5e9b9b738ddca09c2c7bc8d22bc0ed3bad

v0.9.4 de5097efa0a2ab26be19372d871f511ebaaec57e

v0.9.5 2a517a5b34df9b8fd3d4530163d13e910b38b144

v0.9.6 fadb6bb0fcde1eddd10d63b53bb51fabb07ca92d

v0.9.7 6b3650248a79872255ae94e0baa236acb8cab536

v0.9.8 b55f46c453c1b84c5a6358a1c87dc99e823203c1

v0.9.9 2fca297b3fb82201f746c3e417f7764cad97abf0

Austin Wright.

[Ariya Hidayat]

Please describe in slightly more details what problems do you
encounter and why giving the tags would solve it.

Also, I made a choice not to tag any < 1.0 releases because they are
bleeding-edges. Anyone using <= 0.9 might experience weird bugs and
inconsistent behavior. Any projects using these version should move to
1.0.x series, there is no excuse.


Thank you!

Regards,


--
Ariya Hidayat, http://ariya.ofilabs.com
http://twitter.com/ariyahidayat
http://gplus.to/ariyahidayat

[Austin Wright]

Are you looking for something I haven't already described...? You made a 0.9.9 release. I can download it, I can release a npm package that depends on it (dozens of people do!). But there's no "v0.9.9" tag in the Git repository to compliment it. Software tools for examining the history of source coder don't function as well, or in my case, break entirely, when they do not have this information. Not only is it useful for software tools, it's helpful for humans for things like `git blame`.

Being "bleeding edge" has nothing to do with tags. It identifies which commit a release is made from. It doesn't mean it's stable. It doesn't mean it's even usable. Git is where where people go to use bleeding edge releases and unstable code, not in tar.gz releases, so if anything, you should be making GIt tags, and not tar.gz releases of unstable code. The proper place to tag any sort of release, especially development releases, is Git. This helps developers fix bugs and made upgrades, this helps maintainers release properly annotated packages.

Austin Wright.

[Ariya Hidayat]

I'm looking for problems like crashes or bugs or strange behaviors.
What you described:

(1) inconvenience, because one needs to find the SHA1 by hand
(2) inconsistency between your model of releases with what really happened

I made that choice because I wanted to discourage the use of < 1.0
releases. I don't expect everyone to respect that choice. If you
disagree, it's fine by me and we just have to agree to disagree.