Updating a release if you find a mistake in the content is currently only possible through the Releases API. This would be better if it was available as a front-end feature built in since finding a simple typo and quickly editing it would be a common scenario, as well as getting rid of a release.
Good question @jhampton. I think anyone in the project who can create them should be able to edit them, but not exactly sure who that is today. @dosuken123?
May I suggest that it should be possible for the release author to upload release assets, like when creating a tag, but instead of just appending a link to it in the notes it would create a release link.
Thinking out loud, maybe we should extend this form something like:
git-tag/release CURD form
First section - git-tag:
Name of git-tag (textbox, required) ... The new/existing name of a git-tag.
Create from (textbox, required) ... The git-branch name that will be used for git-tag generation (This parameter is effective when the specified git-tag have not been created yet).
Message (textbox, required) ... The git-tag message (This parameter is effective when the specified git-tag have not been created yet).
Second section - Release:
Do you want to create a Release entry, too? (checkbox, required, default => false) ... If true, then show the following Release creation form.
Name of the release (textbox, optional, default => git-tag name) ... The name of the Release. e.g. "Awesome app v1.0 Beta".
Description of the Release (markdown, optional) ... It's already existing as "Release notes". We just rename the field.
Released at (Datetime picker, option, default => now) ... The release date. It can be past or future (i.e. upcoming-releasse).
Asset type (radiobutton, required, default => Link) ... Users can choose asset type from 1. Link 2. Package (Not supported yet) 3. Docker Registry (Not supported yet)
Name of the link (textbox, required) ... The name of the link (e.g. "awesome-v0.2.msi"). Available when asset type is LINK.
URL of the link (textbox, required) ... The URL of the link. Available when asset type is LINK.
The good thing is, Release entries require git-tag existence anyway (if it doesn't exist, it automatically generates one with the given parameter), which means it'd make sense to have both creation/update form in one form like we do today.
Message (textbox, required) ... The git-tag message (This parameter is effective when the specified git-tag have not been created yet).
I believe lightweight (non-annotated) git tags don't (can't?) have a message. So I'd say this field should not be required.
Also, in general, it would be good if it was made clear to the user from a UI perspective whether an annotated git tag or a lightweight git tag is created. See here for the distinction. This could be done e.g. via checkbox, or a "dynamic" message at the bottom "Annotated git tag will be created" or "Lightweight git tag will be created".
It is not good, in my opinion, if it is not 100% clear to the user which of the two git tags will be created (or if there's any "automatic" non-obvious logic behind it like if the message is empty, it's going to create a lightweight tag, and an annotated tag otherwise), before pressing any "Create" button in the GitLab UI.
Also, in general, it would be good if it was made clear to the user from a UI perspective whether an annotated git tag or a lightweight git tag is created.
That's a good call and totally legitimate. In this issue, we're specifically talking about Release associations, so it's out of scope but we should have an issue for that.
In this issue, we're specifically talking about Release associations, so it's out of scope but we should have an issue for that.
Hmm the issue title is "Make it possible to create or edit a release using the UI" which sounds pretty related to me :-). But you're the GitLab employee - Feel free to open another issue with it and add the relevant tags/links, if needed!
Adding the experience baseline recommendations for Releases as related item gitlab-design#505 (closed). There you can see recommendations for improving the functionality and flow for managing Releases via interface. This is part of the Q3 OKR for UX. fyi @cstasik
As per discussion documented here gitlab-design#527 (comment 200229013), this issue is part of the UXOKR for Q3 and needs to be tackled starting on %12.3 (for UX) and %12.4 for development. @jlenny @cstasik could you look into it so we can ensure our Roadmap for release is updated? Right now the milestone assigned is %12.7.
Saving the initial description of the issue in this comment, for posterity:
Problem to solve
Updating a release if you find a mistake in the content is currently only possible through the Releases API. This would be better if it was available as a front-end feature built in since finding a simple typo and quickly editing it would be a common scenario, as well as getting rid of a release.
Add edit button in UX that will allow a release's elements to be edited visually. The edit should be possible for all users who are able to create releases (developer~admin at time of issue creation)
@jlenny As we discussed, this is the main issue I'd like us to prioritize for Q3. We have the opportunity to improve the Persona: Software developer experience here, while we finish collecting the necessary information to build the Release Manager persona ux-research#268 (closed).
We already have a set of recommendations to improve the user experience of this functionality. See gitlab-design#505 (closed).
I will work on this issue in the upcoming days so we can discuss it during our %12.4 chat.
This requires frontend for sure. The scope atm does not provide enough context for what's needed from backend.
GitLab is moving all development for both GitLab Community Edition
and Enterprise Edition into a single codebase. The current
gitlab-ce repository will become a read-only mirror, without any
proprietary code. All development is moved to the current
gitlab-ee repository, which we will rename to just gitlab in the
coming weeks. As part of this migration, issues will be moved to the
current gitlab-ee project.
If you have any questions about all of this, please ask them in our
dedicated FAQ issue.
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to
rename gitlab-ce to gitlab-foss to make the purpose of this FOSS
repository more clear
I created a merge requests for CE, and this got closed. What do I
need to do?
Everything in the ee/ directory is proprietary. Everything else is
free and open source software. If your merge request does not change
anything in the ee/ directory, the process of contributing changes
is the same as when using the gitlab-ce repository.
Will you accept merge requests on the gitlab-ce/gitlab-foss project
after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in
gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git
remotes to use this new URL. GitLab will take care of redirecting Git
operations so there is no hard deadline, but we recommend doing this
as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?