release tags could be inherited by downstream packages using the template

[bsipocz]

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

[astrofrog]

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 😀

[bsipocz]

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)

[pllim]

Hmm. I never noticed that on my packages. Maybe I wasn't templating properly... 😆 Let's pin this.

[pllim]

p.s. While _astropy_init.py is a good indicator, it might still miss some. There is no guarantee that people would not have deleted it afterwards for one reason or another. I guess we can't catch them all.

[pllim]

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 ?

[bsipocz]

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.