Remmina - The GTK+ Remote Desktop Client
v1.4.33
Remmina is a remote desktop client written in GTK+, aiming to be useful for system administrators and travellers, who need to work with lots of remote computers in front of either large monitors or tiny netbooks. Remmina supports multiple network protocols in an integrated and consistent user interface. Currently RDP, VNC, NX, XDMCP and SSH are supported.
|
This page describe the Remmina release workflow, and the steps needed to tag a new version.
A release is the distribution of the final version or the newest version of a software application.
Remmina tries to follow the Semantic Versioning, that means, given a version number MAJOR.MINOR.PATCH, increment the:
Unfortunately, due to the relatively small number of contributions, we almost always increment the PATCH version, even if we push new features.
This is because we are unable to honor the backlog we have for the next MINOR and MAJOR milestones.
That said, is not strictly important to get mad about the versioning, but if we can follow the above schema, is better.
A tag is a pointer to a specific commit, we can have light tags, that can be added and removed as needed and annotated tags. Annotated tags is an unchangeable (nothing is unchangeable ;-) ) par of Git history, and are used on GitLab and GitHub to create a Release. In fact releases are a GitHub, GitLab concept, it doesn't exist in Git, Git knows only about tags and annotated tags.
As soon as we agree to release a new version, we have some preparatory tasks to do, and to be sure to don't miss anything, we work on a new branch and submit a merge request. This is the most important point, as on https://gitlab.com/Remmina/Remmina/-/blob/master/.gitlab/merge_request_templates/Remmina%20Release.md "GitLab" we have a merge request template for the releases. Instructions for generating the changelog can be found here.
master
branch, use a name like rel/v1.4.28
-s
git flag to sign your commit, and push to the Remmina repository.release
label and whatever suit this specific version.At this point we have a Merge Request, be sure everything is fine, or ask for a review.
While you wait, prepare yourself to create the annotated tag, while you can do it from the command line, here we focus on the GitLab web interface.
Open the previous tag, to see it raw, you can edit it (do not save afterwards), this will be useful to cut and paste what is common to all Release we do.
For instance, at https://gitlab.com/Remmina/Remmina/-/releases/v1.4.27/edit you will have to copy:
This will have to be updated in case something has been changed. Pay attention to this point because it's used by the downstream maintainer.
When the MR is merged, and you have all the blocks you need, create a new tag, in that page you have to give a name to the tag, like v1.4.28
, and a message, like Release v1.4.28
. Without that optional message, you will create a lightweight tag, and you won't end-up in a Release.
With the new tag, you can create a Release, in that new page, select the corresponding tag, give a title (follow the previous release as the template), add the change log, and push the Big Red Button :-D
You are done!!
Many things happen behind the scene, as soon as you tag a new version, many systems should detect the new tag, and start to build a new Remmina version, this is true for most of the distro, the flatpak, the Ubuntu Remmina PPA, and the snap (see after). Still, there are some additional manual steps to take.
To access snapcraft you need developer rights, ask one maintainer to add yourself in the developer list. One time a year you need to refresh the snapcraft authentication token:
Better to use dev@r (ask the password to the maintainers), and set emmi na.or gSNAPCRAFT_LOGIN
in the CI/CD variables with the new obtained token.
To get the authors'list I use this git command:
You just need to tailor it a little bit, for instance I remove duplicated entries for authors that have multiple emails, I move up the most active users, but don't be too strict, it shouldn't take more than a couple of minutes.
We should reduce more all the above manual steps, and ideally a Release should happens by itself upon a special merge request, as usual, patches are welcome ;-)