Hi all, my thoughts:
- The structure is a bit confusing: Preparing things to do the release and then the article sends you back to develop to update dependency. - The article reads like releasing is a lot of manual work for building and staging. Can't this be automated via GitHub Actions pipeline? In my other open source project (JUnit Pioneer) we have automated the release, so every maintainer only needs to press a button. >> To the question "all issues should be*assigned*to responsible person, which fixed or merged fix". From all I've seen so far the assigned person is always a Maven maintainer, but it's not guaranteed that the person has done the the fix/implementation or was the person who merged the PR. And issues that are closed as not reproducible anymore (but were a thing in the past) gets closed without assigning a person (but also without a version, so not part of release nots, but "done between last and upcoming release" (I think you get what I mean). So I think this line does not fix the current workflow - and (the work of) non maintaining persons are never be represented as part of the supporting community. The only exception I've seen so far was maven-site issue #631 which was assigned to a contributor. So my suggestion is to slightly rephrase it to "all issues should be assigned the person who has completed, merged, or closed the issue" (and that this can be "everyone" >> Should a PR be assigned to the person who merged it? I don't think this adds any value. And I have not yet recognized that there is a "PR-Leading Maintainer" whos task is to do special things. >> all issues should be fixed and*CLOSED* I would slightly rephrase this to "should be solved and closed" (solved similar to JIRA's "resolution"), because not all issues are bugs that needs to be fixed. >> check existing issues with*Blocker*priority, consider to fix it or change priority if reasonable The GitHub convetions do not list a "Blocker" priority, but only "critical" see https://maven.apache.org/developers/conventions/github.html does not >> If a component has a history of release notes at*GitHub*, we should to continue maintain it in order to avoid user confusing. "should", means no "has to". So the releasing person could also decide to write them on social media? Yes - together with the following lines about the three options about releases notes it gets clearer that there must be some kinf of releases notes (at least a link) on Github. But with more and more issues moving to Github the options to "Put a link to release notes in JIRA" does not makes sense to me. ALso the paragraph does not consider the way if there are github issues and jira issues (might be a Maven site only thing where issues do not get migrated). >> Successful vote I would add the +0 and -1 votes in the example. I know that all of you do this (at least I have not seen a successful vote mail without), but if you only read the example you could cut the information that a vote might be close of positive and negatives one [the rules allow that such releases might still be done]. >> Unsuccessful vote The example in this paragraph does not fit the heading. An unsuccessful vote has a different meaning compared to a canceled one (even if both have the same result that a released will not happen). - Matthias Am 11.01.2025 um 14:15 schrieb Slawomir Jaranowski:
Hi, We should update a release procedure [1] One question, we have: "all issues should be assigned to responsible person, which fixed or merged fix" Should be the same for GitHub issues and PR? It can be done automatically. [1]https://maven.apache.org/developers/release/maven-project-release-procedure.html
