jakirkham commented 8 years ago

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 commented 2 years ago

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	7fba28995396bc88545cda6bbd605368c7baeb4b	matched `ipycache.py`; next commit changed `setup.py` version number
0.1.3	Oct 10, 2013	1f75739d67c84fba307181e4568c6b38721742ce	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	216cc6a7cd9a8c352dafb2a5a1133c5d64387545	matched `ipycache.py`; next commit updated version number in `setup.py`
0.1.1	Oct 8, 2013	421c2831ae958f821d6b96a7aaede5ab9cd1b9b5	matched `ipycache.py`; also the only commit with `setup.py` version set to `0.1.1`
0.1.0	Oct 8, 2013	f32e4616b4bd9aab041fda37c43a3f8be39db395	matched `ipycache.py`

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

rossant commented 2 years ago

Looks good! :pray:

mbrukman commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Great thank you! 😄

Feel free to close when you are ready

mbrukman commented 2 years ago

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:

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":

https://github.com/rossant/ipycache/blob/8fd456233529e20bc4c998b089ec15e455335d18/setup.py#L26

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

Now we're done.

rossant / ipycache

Adding tags for corresponding releases #42

Create tags

Test on my own repo

Push upstream