Revise Release Procedure #20
Conversation
TCW/tcw22.xml
Outdated
| <item>Paste the result into a text editor and remove any linebreaks added by the | ||
| terminal.</item> | ||
| <item>Copy-paste the result into | ||
| https://sourceforge.net/auth/shell_services</item> |
There was a problem hiding this comment.
Do we want to make this ref to sourceforce a URL too?
There was a problem hiding this comment.
Well spotted. I've added that ref now.
TCW/tcw22.xml
Outdated
| <item>Label the issue as Release Note (green label) if it’s important to include the note about it in Release Notes</item> | ||
|
|
||
| </list> | ||
| <head>Issue Handling Recommendations</head> |
There was a problem hiding this comment.
Two questions: (1) should we refer to the Council policy re release milestones as discussed in the Kraków F2F? See page 6/7 of the minutes; (2) Is this section at its right place, here? This seems like more general guidelines as how to handle milestones and release notes, intended not only for the release technicians but for all council members and council chair.
There was a problem hiding this comment.
I agree that the Issue Handling Recommendations sections should come earlier in the document. I think it should come before the Packages on GitHub section since it is general guidance for all Council members.
Regarding point (1), I am adding the relevant section from the minutes here for ease of reference:
The setting of milestones
When to set a release milestone on a given issue?
The ticket assignee should determine if it will be ready for the next release, rather than presume that every ticket can be solved for a release.
Council agrees to create an extra release milestone “future release” for long-range issues especially (since we cannot be sure what the future release version numbers will be). SB created one.
Action on Council members to add a comment to any tickets that haven’t been addressed in a specific release and remove the milestone from the ticket, so that the council chair doesn’t have to do this in preparation for the release.
| packages. (The GPG private key itself is hosted on the server at the default | ||
| location.)</item> | ||
| <!-- Revisit the above item, which was called into question during February 2020 release. | ||
| If Debian package update is not the responsibility of release technician(s), |
There was a problem hiding this comment.
What do we do with this comment? Do we integrate it into the running text? Or does the comment hold and is the Debian package update not part of the responsibility of the release techs?
| <item><hi rend="bold">Get p5subset.xml</hi> from a fresh build of the P5 dev branch (preferably on Jenkins, at a URL such as | ||
| https://jenkins.tei-c.org/job/TEIP5-dev/lastSuccessfulBuild/artifact/P5/release/xml/tei/odd/p5subset.xml) and | ||
| update the version of p5subset.xml in the Stylesheets/source directory in the Stylesheets dev branch.</item> | ||
| <item>Inform the Jenkins maintainers (who may not be on the Council listserv), and the |
There was a problem hiding this comment.
There are a number of references to the Jenkins maintainers, sometimes identifying them by name, sometimes not. In line 281/282, for example, the Jenkins maintainers are listed as Peter Stadler, Martin Holmes and Raff. In line 198 below, it's "just" Peter and Martin. Should we aim for consistency here?
There was a problem hiding this comment.
Thank you for highlighting this, I've addressed this omission now.
TCW/tcw22.xml
Outdated
| <item>The instructions below for Git commands are assumed to be run in the release-X.X.X | ||
| branches unless otherwise specified. If you did not create the release branch, you can | ||
| branches unless otherwise specified. If you did not create the release branch, you can | ||
| set up a copy of it using the following commands:<lb/> |
There was a problem hiding this comment.
Perhaps it's better to phrase this as "If you did not create the release branch yourself, set up a copy of it using the following commands:..." The current phrasing makes creating a copy of the release branch as optional, but this is aimed at the other release technicians, right?
There was a problem hiding this comment.
Have attempted to clarify the above by rephrasing the above as follows:
If there is more than one release technician, one
of the release technicians should create the release branch and the other release
technicians can set up a copy of the release branch using the following commands:
martindholmes
left a comment
martindholmes
left a comment
There was a problem hiding this comment.
This looks slightly wrong to me:
<item>Don’t forget to change directory to the released branch <code>git checkout released</code></item>
It's not a question of changing directory; rather it's changing branch.
Following the Release of Guidelines 4.10.0 and Stylesheets 7.59.0, @HelenaSabel, @bleekere and I decided that it would be a good idea to prepare a report on the release procedure for the upcoming TEI 2025 F2F and conference at Krakow. This PR serves as a means of storing any corrections as well as recommended updates to facilitate a more efficient release process.