Yes, I think the idea of pausing commits on main during the release process and creating a branch for the release is good. To prevent the hash to change, I think we should use the final version number in the pom.xml file. For instance, we may have 0.7.1 in the pom and name the corresponding tag v0.7.1-rc1.
I will summarise try to summarise this process in a README file and launch the release process, so we have a first release before the next report. > On 4 Mar 2023, at 00:09, Julian Hyde <jhyde.apa...@gmail.com> wrote: > > If you give each RC a tag, and push that tag, then you are not removing the > commit. The commit is still reachable via the tag. > > One possible process is as follows. You could pause commits to main during > the release process. Make the release candidates on a branch that is one > commit ahead of main. If an RC vote fails, you can force-push the next RC to > the same branch. When the vote passes, push that commit to main, re-open main > for pushes, and delete the branch. > > (In Calcite we pause commits during the release process. We find that this is > OK because Calcite is fairly low velocity, and people like having a clean git > history. In high velocity projects like Spark, pausing commits would not be > practical.) > >> On Mar 3, 2023, at 9:23 AM, Josh Fischer <j...@joshfischer.io> wrote: >> >> I think an issue may arise with removing commits associated with RC's. >> When we start a vote, we list the commit hash of the source package to be >> voted upon. If you remove those commits, I believe it would invalidate the >> work put into the voting process, as that commit doesn't exist anymore and >> the release wouldn't be valid anymore. >> >> As long people can download packages and verify signatures match exactly >> what was voted on and approved, I think we should be good to go. >> >> >> An example of the start of our old vote template is below. >> >> >> ### start template ### >> Hello Heron Community, >> >> This is a call for a vote to the 4th release candidate for Apache Heron, >> version 0.20.5-incubating. >> >> We request project mentors (binded) as well as all contributors (unbinded) >> and users to review and vote on this incubator release. >> >> * The tag to be voted upon: 12b8abc152f7a23e87ef19299ff92423a6ee1469 >> The full list of changes and release notes are available >> at: >> https://github.com/apache/incubator-heron/releases/tag/0.20.5-incubating-rc4Files >> >> >> ... yadda yadda yadda.... >> >> On Fri, Mar 3, 2023 at 10:36 AM Bertil Chapuis <bchap...@gmail.com> wrote: >> >>> Our release process currently relies on the maven release plugin. It >>> changes the version number in all our pom.xml files, commit the changes, >>> and creates a tag for the release. If this tag starts with the letter “v” a >>> release workflow will be started by GitHub actions [1]. >>> >>> We could create a tag off of main without executing the maven release >>> plugin, however, the version number in the pom.xml file will not match with >>> the tag. The other possibility is to work in a branch, remove commit >>> associated with release candidates and keep the history as clean as >>> possible. >>> >>> I guess the best would be to chose one option. Executing it will allow us >>> to refine it in the future. >>> >>> [1] https://maven.apache.org/maven-release/maven-release-plugin/ >>> >>>> On 3 Mar 2023, at 16:02, Josh Fischer <j...@joshfischer.io> wrote: >>>> >>>> In the past with Heron, I created release candidates as tags off of main >>>> and marked them as a pre-release. >>>> >>>> The tag name would be something like: >>>> >>>> heron-0.20.5-incubating-rc1 >>>> >>>> Then we would do a vote etc. Once the vote passed or failed the tags >>>> remained In the repo. >>>> >>>> Not saying it must be done this way. This is part of the way, in my >>>> experience, I managed to get release candidates to pass voting on dev@ >>> and >>>> general@ >>>> >>>> >>>> >>>> On Fri, Mar 3, 2023 at 6:59 AM Bertil Chapuis <bchap...@gmail.com> >>> wrote: >>>> >>>>> Ok, so the process would be to make a release candidate and then to ask >>>>> the mentors to vote on the mailing-list. Is that right? >>>>> >>>>> Can the release candidate be in a branch, so that we can remove it once >>>>> the vote passes and the final release is published? >>>>> >>>>> >>>>> >>>>>> On 3 Mar 2023, at 13:54, Josh Fischer <j...@joshfischer.io> wrote: >>>>>> >>>>>> We still need to have mentors vote on the release even if we have the >>> WIP >>>>>> disclaimer. >>>>>> >>>>>> On Fri, Mar 3, 2023 at 6:50 AM Bertil Chapuis <bchap...@gmail.com> >>>>> wrote: >>>>>> >>>>>>> Hello Everyone, >>>>>>> >>>>>>> Would someone (maybe Andrea or James) be interested to write the next >>>>>>> report? I think it is a good idea if we start rotating this task. >>>>>>> >>>>>>> Since the last report, we released a new version of the web site and >>> we >>>>>>> may still be able to drop a first incubating release with a >>>>> DISCLAIMER-WIP >>>>>>> file. I don’t think we have to vote for this kind of release, but >>> maybe >>>>> one >>>>>>> of our mentors may clarify the process. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Bertil >>>>>>> >>>>>>>> On 2 Mar 2023, at 08:46, jmcl...@apache.org wrote: >>>>>>>> >>>>>>>> Dear podling, >>>>>>>> >>>>>>>> This email was sent by an automated system on behalf of the Apache >>>>>>>> Incubator PMC. It is an initial reminder to give you plenty of time >>> to >>>>>>>> prepare your quarterly board report. >>>>>>>> >>>>>>>> The board meeting is scheduled for Wed, 15 March 2023. >>>>>>>> The report for your podling will form a part of the Incubator PMC >>>>>>>> report. The Incubator PMC requires your report to be submitted 2 >>> weeks >>>>>>>> before the board meeting, to allow sufficient time for review and >>>>>>>> submission (Wed, March 01). >>>>>>>> >>>>>>>> Please submit your report with sufficient time to allow the Incubator >>>>>>>> PMC, and subsequently board members to review and digest. Again, the >>>>>>>> very latest you should submit your report is 2 weeks prior to the >>> board >>>>>>>> meeting. >>>>>>>> >>>>>>>> Candidate names should not be made public before people are actually >>>>>>>> elected, so please do not include the names of potential committers >>> or >>>>>>>> PPMC members in your report. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> The Apache Incubator PMC >>>>>>>> >>>>>>>> Submitting your Report >>>>>>>> >>>>>>>> ---------------------- >>>>>>>> >>>>>>>> Your report should contain the following: >>>>>>>> >>>>>>>> * Your project name >>>>>>>> * A brief description of your project, which assumes no knowledge >>> of >>>>>>>> the project or necessarily of its field >>>>>>>> * A list of the three most important issues to address in the move >>>>>>>> towards graduation. >>>>>>>> * Any issues that the Incubator PMC or ASF Board might wish/need to >>>>> be >>>>>>>> aware of >>>>>>>> * How has the community developed since the last report >>>>>>>> * How has the project developed since the last report. >>>>>>>> * How does the podling rate their own maturity. >>>>>>>> >>>>>>>> This should be appended to the Incubator Wiki page at: >>>>>>>> >>>>>>>> https://cwiki.apache.org/confluence/display/INCUBATOR/March2023 >>>>>>>> >>>>>>>> Note: This is manually populated. You may need to wait a little >>> before >>>>>>>> this page is created from a template. >>>>>>>> >>>>>>>> Note: The format of the report has changed to use markdown. >>>>>>>> >>>>>>>> Mentors >>>>>>>> ------- >>>>>>>> >>>>>>>> Mentors should review reports for their project(s) and sign them off >>> on >>>>>>>> the Incubator wiki page. Signing off reports shows that you are >>>>>>>> following the project - projects that are not signed may raise alarms >>>>>>>> for the Incubator PMC. >>>>>>>> >>>>>>>> Incubator PMC >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@baremaps.apache.org >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org >>>>>>> For additional commands, e-mail: dev-h...@baremaps.apache.org >>>>>>> >>>>>>> -- >>>>>> Sent from A Mobile Device >>>>> >>>>> -- >>>> Sent from A Mobile Device >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org >>> For additional commands, e-mail: dev-h...@baremaps.apache.org >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org > For additional commands, e-mail: dev-h...@baremaps.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@baremaps.apache.org For additional commands, e-mail: dev-h...@baremaps.apache.org
