github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-16 21:23:02 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Release date keeps getting updated even if you're updating the content of the release notes #5791

New Issue
Closed
opened 2025-11-02 06:36:06 -06:00 by GiteaMirror · 1 comment
GiteaMirror commented 2025-11-02 06:36:06 -06:00
Owner
Copy Link

Originally created by @richmahn on GitHub (Jul 27, 2020).

  • Gitea version (or commit ref): 1.12.2
  • Git version: 2.14.5
  • Operating system: MacOS
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
    • Not relevant
  • Log gist:

Description

When I make a release, the created unix time gets set to the time I make the release, no the commit, which is right.

Yet if I now update my release by editing its content, its date changes.

This is a problem if I update an old release, such as tell users not to use, it becomes the release at the top of the release page!

Related to this change: https://github.com/go-gitea/gitea/pull/11218

Basically you should only change the release created_unix if it is making an actual tag (going from Draft to pre-release or release), do not touch it if updating a release or pre-release.

...

Screenshots

On try.gitea.io, making two releases v1, then v2, then edit v1. It now is at the top.

Screen Shot 2020-07-27 at 3 39 54 PM
Screen Shot 2020-07-27 at 3 40 14 PM
Screen Shot 2020-07-27 at 3 40 32 PM

Originally created by @richmahn on GitHub (Jul 27, 2020). - Gitea version (or commit ref): 1.12.2 - Git version: 2.14.5 - Operating system: MacOS - Database (use `[x]`): - [ ] PostgreSQL - [X] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [X] Yes (provide example URL) - [ ] No - [ ] Not relevant - Log gist: ## Description When I make a release, the created unix time gets set to the time I make the release, no the commit, which is right. Yet if I now update my release by editing its content, its date changes. This is a problem if I update an old release, such as tell users not to use, it becomes the release at the top of the release page! Related to this change: https://github.com/go-gitea/gitea/pull/11218 Basically you should only change the release created_unix if it is making an actual tag (going from Draft to pre-release or release), do not touch it if updating a release or pre-release. ... ## Screenshots On try.gitea.io, making two releases v1, then v2, then edit v1. It now is at the top. ![Screen Shot 2020-07-27 at 3 39 54 PM](https://user-images.githubusercontent.com/2839925/88584452-a213ed80-d01f-11ea-8d18-6f2744941feb.png) ![Screen Shot 2020-07-27 at 3 40 14 PM](https://user-images.githubusercontent.com/2839925/88584457-a2ac8400-d01f-11ea-9174-176a95d60822.png) ![Screen Shot 2020-07-27 at 3 40 32 PM](https://user-images.githubusercontent.com/2839925/88584460-a3451a80-d01f-11ea-8fc1-8272b24e51af.png)
GiteaMirror commented 2025-11-02 06:36:07 -06:00
Author
Owner
Copy Link

@richmahn commented on GitHub (Jul 27, 2020):

I'll probably end up working on this anyway. Will make a fix.

@richmahn commented on GitHub (Jul 27, 2020): I'll probably end up working on this anyway. Will make a fix.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#5791
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?