Adding tags for corresponding releases

[jakirkham]

It would be really helpful if we could have tags for corresponding releases here. In particular, this would help us checkout that release and test it before we package and ship it in conda-forge.

cc @jochym

[mbrukman]

Looking at https://pypi.org/project/ipycache/#history, we have the following releases and I've found the commit hashes that were most likely responsible for them, primarily by matching ipycache.py at that commit to the file in the release zip file (from PyPI), and in some cases, using additional information where a release was published where the last change was not to ipycache.py itself:

Version	Date	Commit hash	Rationale
0.1.4	Oct 13, 2013	7fba289	matched ipycache.py; next commit changed setup.py version number
0.1.3	Oct 10, 2013	1f75739	matched ipycache.py; also, release was done before the fix to README to add missing backtick; see the extra backtick on https://pypi.org/project/ipycache/0.1.3/
0.1.2	Oct 9, 2013	216cc6a	matched ipycache.py; next commit updated version number in setup.py
0.1.1	Oct 8, 2013	421c283	matched ipycache.py; also the only commit with setup.py version set to 0.1.1
0.1.0	Oct 8, 2013	f32e461	matched ipycache.py

@rossant — would you like to double-check these commit hashes before I create tags for these historical releases?

[rossant]

Looks good! 🙏

[mbrukman]

Since one cannot create tags for historical commits via the GitHub UI, my plan is to do this via CLI and push it as follows:

Create tags

Note: to create tags which have the same date as the commit, we set the GIT_COMMITTER_DATE env var as per this post.

#!/bin/bash

# 0.1.0
git checkout f32e4616b4bd9aab041fda37c43a3f8be39db395
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag 0.1.0

# 0.1.1
git checkout 421c2831ae958f821d6b96a7aaede5ab9cd1b9b5
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag 0.1.1

# 0.1.2
git checkout 216cc6a7cd9a8c352dafb2a5a1133c5d64387545
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag 0.1.2

# 0.1.3
git checkout 1f75739d67c84fba307181e4568c6b38721742ce
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag 0.1.3

# 0.1.4
git checkout 7fba28995396bc88545cda6bbd605368c7baeb4b
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag 0.1.4

Test on my own repo

Push the tags to my fork of this repo (for me, this is origin) to see how this works:

#!/bin/bash

for tag in 0.1.{0,1,2,3,4}; do
  git push origin "${tag}"
done

Push upstream

Assuming the push to my fork goes well and looks good, push to this repo (for me, this repo is upstream):

#!/bin/bash

for tag in 0.1.{0,1,2,3,4}; do
  git push upstream "${tag}"
done

[mbrukman]

Create tags locally:

# 0.1.0
git checkout f32e4616b4bd9aab041fda37c43a3f8be39db395
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag 0.1.0

# 0.1.1
git checkout 421c2831ae958f821d6b96a7aaede5ab9cd1b9b5
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag 0.1.1

# 0.1.2
git checkout 216cc6a7cd9a8c352dafb2a5a1133c5d64387545
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag 0.1.2

# 0.1.3
git checkout 1f75739d67c84fba307181e4568c6b38721742ce
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag 0.1.3

# 0.1.4
git checkout 7fba28995396bc88545cda6bbd605368c7baeb4b
GIT_COMMITTER_DATE="$(git show --format=%aD | head -1)" git tag 0.1.4

Local verification:

$ git show-ref --tags
f32e4616b4bd9aab041fda37c43a3f8be39db395 refs/tags/0.1.0
421c2831ae958f821d6b96a7aaede5ab9cd1b9b5 refs/tags/0.1.1
216cc6a7cd9a8c352dafb2a5a1133c5d64387545 refs/tags/0.1.2
1f75739d67c84fba307181e4568c6b38721742ce refs/tags/0.1.3
7fba28995396bc88545cda6bbd605368c7baeb4b refs/tags/0.1.4

Looks good!

Here's my git remote config (for context on the following set of commands):

origin	git@github.com:mbrukman/ipycache.git (fetch)
origin	git@github.com:mbrukman/ipycache.git (push)
upstream	git@github.com:rossant/ipycache.git (fetch)
upstream	git@github.com:rossant/ipycache.git (push)

Pushing to my own repo:

for tag in 0.1.{0,1,2,3,4}; do
  git push origin "${tag}"
done

Looks good!

https://github.com/mbrukman/ipycache/tags has all the expected tags with expected commit hashes, and in particular, the dates of the tags match the dates of the commits, so looks good from a historical perspective as well.

Finally, pushing to this repo:

for tag in 0.1.{0,1,2,3,4}; do
  git push upstream "${tag}"
done

Looks good!

https://github.com/rossant/ipycache/tags has the expected content as well.

[jakirkham]

Great thank you! 😄

Feel free to close when you are ready

[mbrukman]

We're almost done, but not quite yet! I figured I might as well finish this rather than open another bug to re-create all releases as well.

The tags are all there, and since we now have good tags, we can create releases from those tags, so that folks can easily download snapshots from this repo (though they can also easily do this from PyPI as well) — the main value I see is that GitHub makes it really easy to add a link to show all the changes that have gone into the release, so you can see the delta between release N and N+1.

We now have following releases:

• https://github.com/rossant/ipycache/releases/tag/0.1.4
• https://github.com/rossant/ipycache/releases/tag/0.1.3
• https://github.com/rossant/ipycache/releases/tag/0.1.2
• https://github.com/rossant/ipycache/releases/tag/0.1.1
• https://github.com/rossant/ipycache/releases/tag/0.1.0

This means that the GitHub release history page (https://github.com/rossant/ipycache/releases) now matches the PyPI release history (https://pypi.org/project/ipycache/#history).

FWIW, I marked all releases as "pre-release" since the version numbers are 0.y.z, and since setup.py labels this software as "alpha":

ipycache/setup.py

Line 26 in 8fd4562

"Development Status :: 3 - Alpha",

At some point, maybe we should create a "stable" release, but that's a conversation for another day.

Now we're done.