Delete tag latest in Oolite repo?

[mcarans]

There is a tag latest in the main Oolite repo that messes with readthedocs. latest should usually refer to the latest commit on the default branch, in this case master, but the manual creation of a latest tag prevents that from working. I propose to delete the latest tag. Does anyone have any issue with this? Is anything relying on that tag which points here: https://github.com/OoliteProject/oolite ... 704e98802c?

[hiran]

For %reasons% I am offline at the moment and thus cannot download or investigate.

The abovementioned commit does not introduce any messing with tags - or I may have misunderstood. What exactly is the problem?

[mcarans]

For %reasons% I am offline at the moment and thus cannot download or investigate.

The abovementioned commit does not introduce any messing with tags - or I may have misunderstood. What exactly is the problem?

I don't know who created the tag only who created the commit that was tagged. The tag is here: https://github.com/OoliteProject/oolite ... tag/latest

The problem is this. By default, Read the Docs points the URL oolite.readthedocs.io/en/latest/ to the repository's default branch. The manually created Git tag named latest confuses RTD so that it tries to build the tag instead of the master branch.

It sounds like you don't know about the tag, so unless someone gets back to say they need it I'll go ahead and delete it.

[hiran]

For %reasons% I am offline at the moment and thus cannot download or investigate.

The abovementioned commit does not introduce any messing with tags - or I may have misunderstood. What exactly is the problem?

I don't know who created the tag only who created the commit that was tagged. The tag is here: https://github.com/OoliteProject/oolite ... tag/latest

The problem is this. By default, Read the Docs points the URL oolite.readthedocs.io/en/latest/ to the repository's default branch. The manually created Git tag named latest confuses RTD so that it tries to build the tag instead of the master branch.

It sounds like you don't know about the tag, so unless someone gets back to say they need it I'll go ahead and delete it.

*If* that tag gets created by the build process I guess it should point to the head of the master branch. But then Github calls the latest release 'latest' (I am not referring to the build tagged pre-release). It makes sense to display that version's docs as latest rather than some development status.

Releases are not created automatically. Per definition it is a manual process. That one should likely move the latest tag as well. So at rhis point in time the latest tag should be on the commit that produced
https://github.com/OoliteProject/oolite ... s/tag/1.92

[mcarans]

*If* that tag gets created by the build process I guess it should point to the head of the master branch. But then Github calls the latest release 'latest' (I am not referring to the build tagged pre-release). It makes sense to display that version's docs as latest rather than some development status.

Releases are not created automatically. Per definition it is a manual process. That one should likely move the latest tag as well. So at rhis point in time the latest tag should be on the commit that produced
https://github.com/OoliteProject/oolite ... s/tag/1.92

I have deleted the tag and run the readthedocs build. Tags should only be versions. readthedocs has a separate label for pointing to last release: stable. Since readthedocs was not in the 1.92 release but is only on master, using stable could only be set up for the next release.

Note to all developers with write access to the Oolite repo: for existing cloned repositories, this command needs to be run to sync local tags with remote (removes local tags not on the remote). This ensures the tag isn't accidentally pushed back again in future by a git push --tags or a git push --all:

Code: Select all

git fetch --prune --prune-tags

[hiran]

I have deleted the tag and run the readthedocs build. Tags should only be versions. readthedocs has a separate label for pointing to last release: stable. Since readthedocs was not in the 1.92 release but is only on master, using stable could only be set up for the next release.

Sounds like you know what you are doing. Move on...