Backdating a release to the tag date

[IldarKhayrutdinov]

As continue https://github.community/t/backdating-a-release-to-the-tag-date/120161

It would be great to be able to manually set the release date.

[eyalroz]

Repeating my comment on the community forum: This is especially useful for when you're importing a repository with tags. After importation, when you create releases here on GitHub - they will be dated to right-now, not to when the tag was created or some appropriate time in the past.

[jgivoni]

I'm very interested in this functionality too. Sometimes you just have to correct something and not having the releases on the correct date and in the correct order just makes things confusing.

[MylesBorins]

Copying an answer from #6646 with minor tweaks.

Currently there are at least 2 dates associated with the release, and potentially as many as 3!

You have:

The date of the commit
The date of the tag
The date of the GitHub Release

Here's where things get tricky. By default a tag is not annotated (docs)... this means the tag has no specific meta data associated with it (such as author or date) and is just a loose pointer to a commit. You need to run tag with -a, -s, -f, or -m to make an annotated tag that has all of this additional information.

So here is where it gets fun! Let's say you made a release candidate, and that RC is the exact same commit as your release, but you use non annotated tags. On our end we actually don't know the difference between the two tags aside from the fact that they have different names, and depending on the way you are doing alphabetical sort 1.2.3-rc.1 could sort above 1.2.3... not the outcome you want!

So we use the release date of the GitHub release to be the canonical date of the "GitHub release", but it is not meant to be a substitution for the tag or commit. In fact we use the tag / commit date to sort releases rather than the GitHub Release date to ensure we order releases based on their canonical release date, not the date of the GitHub Release

That said, if someone made a release candidate and promoted it to be a full release using non annotated tags we could end up with a date that is before the actual release.

On to the suggested solution. We could allow for a customized release date, but considering we already have 3 different ways of making the date, and that you can customize the date of the tags itself I don't think it would be a good idea for us to introduce a 4th possible date.

We do show the GitHub Release date as the primary date in the feed and on the release itself, which is something that we could explore changing... but for the 99% case the GitHub Release date is likely to be the expected date of the release, and if you think of it like a blog post, the publish day of the post is the "day" of the GitHub release.

Anyways... apologies for the many many words to say "it's complicated"... but unfortunately like most times when dealing with computers, dates are hard 🙃

[eyalroz]

but for the 99% case the GitHub Release date is likely to be the expected date of the release,

This whole discussion started because that statement is incorrect: When you import a repository into GitHub, you create releases for the tags, and the GitHub release creation date is certainly not the expected date.

This also happens on any repository when you recreate releases after they were removed for some reason, or when you decide retroactively that some tag is worthy of a release.

it's complicated ... dates are hard upside_down_face

This is only complicated if you want to force a single dating scheme always. If you let repository owners choose between the dating schemes, I don't really see the complication.

[jegelstaff]

Agreed. It would not be complicated to simply allow editing of the release's date when you create the release, or later if you're editing the release. This does not introduce another date. It just gives people control over a date that they otherwise have no control over.

I am creating historical releases for my project. These releases happened a long time ago, before we were even using GitHub. I can date the tags, yes, so the releases show up in order on the release page. But the date shown for these ancient releases is the day I made the release on GitHub. That is silly, and simply being able to edit the release date would fix the issue.

Saying it's complicated is an excuse. If it's a won't-fix, fine. Just say so.
--Julian

[floge07]

A checkbox like "Use tag creation date as release date" would be all that is needed imo.

Especially considering that git itself already has options to set timestamps as you want to (setting GIT_COMMITTER_DATE also works for tags).

So GitHub wouldn't even need to implement a whole lot of "specify release date" features with datetime picker and so on. Just pass through the tag creation date. Release drafts are already doing that.

[mikrosk]

I agree with @eyalroz -- there's nothing complicated with adding a combo box when drafting a release to choose whether you are interested in tag's date or current date.

[ib]

I totally agree with @eyalroz and @mikrosk.

[doublerebel]

Confusingly, a draft created from a tag shows the date of the commit, not the date the draft was created -- which makes it seem that will be the date when published. However when changed to published, the date changes to the publish date.

[janbrasna]

That! ^

Had a happy draft, showing the proper date of a (forgotten) tag that I'm backfilling the release for… and yea, exactly, after publishing, the date just jumped to now. What a letdown!

[tristanjahier]

If you created tags but forgot to create the associated GH releases immediately, then the dates will be messed up. And that's irritating.

[kelly-sovacool]

Bumping this as I'm still interested in a solution such as https://github.com/orgs/community/discussions/5447#discussioncomment-1875477

[billybooth]

Bumping again. Simply being able to edit the release date via the web or releases API would be sufficient for us.

[easterncoder]

Was about to create a bunch of releases from a bunch of tags. So yeah, bumping too.

[IldarKhayrutdinov]

Obviously, the release date (release publication date) does not always equal to date of release page creation. What is now on github is the date of release page creation, release notes page. For various reasons: when migrating a repository from another hosting, when forgot to create release page, anything happens.

We could separate the date of page creation and the date of release itself. As wrote above, we can let the user to select between the current date and the tag date (for an exist tag and tag date != current date). The user can create tag with a desired date to desired commit. We should sort releases by release date, not by page creation date.

[otherguy]

Was about to turn a bunch of draft releases with correct dates into public release. So yeah, bumping too.

[Joz3d]

Bumping because wanted to migrate code to GitHub and create historical releases of the various versions, which came out many years ago, not today.

[veggiemike]

Wow, kinda bummed this hasn't been addressed yet. I too have past pre-github releases that I would like to be able to include in "Releases" but not have released today. Seems like a pretty common request/problem.

[digitalghost-dev]

I’m dealing with this issue now and it’s irritating. I have 3 releases that were originally released last fall. Because of a mistake, I had to retag commits and now the releases are all showing the same release date of an hour ago which throws off the timeline. I hope that this is taken more seriously.

[jegelstaff]

In case you don't know, the best you can do is set the date of the tags to some date in the past. So the releases will at least appear in order based on the tag dates. But the date shown for the release in GitHub will still be wrong, it will always be the date the release was created.

More info: https://stackoverflow.com/questions/21738647/change-date-of-git-tag-or-github-release-based-on-it

Good luck!

[digitalghost-dev]

@jegelstaff - thanks for the input. I guess that’s what this whole discussion is about. The crazy part is that this seems doable in GitLab!

update a release