-
-
Notifications
You must be signed in to change notification settings - Fork 63
release tags could be inherited by downstream packages using the template #512
Comments
If we wanted to fix this we could automatically go through repos that include an _astropy_init.py file, check the tag dates against the template and open an issue listing the tags that can be deleted safely and how to do it? Or we could just document it 😀 |
Yes, that's what I meant with 'batchissuing'. Which may be a bit over the board given a proper cleanup is difficult as those tags may come back from forks, too (same that happened in astropy with those really old tags) |
Hmm. I never noticed that on my packages. Maybe I wasn't templating properly... 😆 Let's pin this. |
p.s. While |
So, if a repo accidentally inherited the tags from this template, will their tags match exactly (or is subset of) the list in https://github.com/astropy/package-template/releases ? |
yes, the tags will be matched (https://github.com/astropy/package-template/tags). So date, or committer, or commit message could be used to double-check. |
As far as my Github-fu allows, I found 346 repos with |
Yeah, we don't really support bringing the whole commit history anymore, so they would not see the tags. |
@bsipocz , should we close this as resolved then? Not sure what else we can do here. |
Packages that use the template with the history may inherited release tags corresponding to the package template. With cookiecutter this may not be an issue any more as no commit details, metadata, credits, etc are inherited, nevertheless there could be many tags inherited that package authors may want to cleanup.
(See e.g. astroquery. I've cleaned up the main repo, but the errenous tags of e.g. v0.4.1, v1.0, v1.1, etc are still around in people's forks who forked after those changes from the template were applied to the repo).
Action item: document this, maybe batchissue it to affected users
The text was updated successfully, but these errors were encountered: