All - Given no comments on the below email, and to my previous emails about this release....
I am changing the release process in minor ways and I am keeping you informed that the tag 1.10 will be recreated in the coming days. We have a few more priority issues to resolve prior to this release. The main change is that we do not need to stop development as we expect all code commits to be non breaking. See "How to Release Apache Fineract" process documented at https://cwiki.apache.org/confluence/x/DRwIB (updated) I will re-create a Tagged 1.10draft-release off develop in our git repository at https://github.com/apache/fineract on 25 April 2024. (or at my discretion in the days after) That will be visible as a tagged "draft release" in GitHub. The release tracking umbrella issue for tracking all activity in JIRA is FINERACT-2077 https://issues.apache.org/jira/browse/FINERACT-2077 All activity in JIRA is Fineract release=1.10. I will be verifying and correcting so that the release notes will match the actual fixes in code. https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12352223&styleName=Text&projectId=12319420&Create=Create&atl_token=A5KQ-2QAV-T4JA-FDED_e2d49e9dc3d17897e31c45f37b745624b38be28c_lin *If you have specific work in progress that will impact this release, please add "blocking" links to the release JIRA issue 2077 above prior to 25 April 2024. (72 hrs from now) * I am the release manager for this release. But, I will be relying on help from several people. Thanks, James On Wed, Apr 10, 2024 at 6:09 PM James Dailey <jdai...@apache.org> wrote: > > All - Given the significant changes to the code since the January release of 1.9, I've gone with the whole number of 1.10. Thus, this is not 1.9.1, but 1.10.0. Proposed release "One point ten", publicly describing this as "processing".... NOT YET A RELEASE. > > https://github.com/apache/fineract/releases/tag/1.10 > > The process that is described in our documentation is out of date. > https://cwiki.apache.org/confluence/display/FINERACT/Fineract+Releases > > Here is my proposed happy-path process and where I am at: > > Inform the dev list at least 2 weeks in advance that a tag is coming for a release with a specific date. > Keep reminding people to make any changes stable and to pay special attention to this tag day. NOTE: At all times we should have a stable release possible, so the ask here is that if this is NOT the case, someone mentions it. > Do a pre-release tag and auto generated the changeset > Finalize and document the list of Fixed tickets [I AM HERE] that correspond to the changesets and put them into Wiki page per the pattern. > > Look at those Jira Tickets that have been closed and fixed since the last release. > If there are changesets that have NO corresponding Ticket, I will send out flames, I mean to say carefully written emails to the responsible devs to FIX it, and never again. > This also means trying to sort through tickets that people have tagged as "to be fixed in 1.10" which are not in fact going to be fixed in this release, as they are not ipso facto fixed. > > Check any open Security issues (open CVEs) and kick off any required process there. > Push the tag as a Release (no longer "pre-release"), also download the code assets and push that code snapshot to SVN draft release > Immediately call for a VOTE based on the SVN release information. Require everyone to note if they built the project successfully, i.e. modelling the release process that ASF will likely be adopting globally. > After at least 72 hrs, tally votes for the release, describe the votes in detail. > Move from SVN draft to SVN release on Apache Infra > Make announcement on list and in proper places at Apache Infra > > All of this is intended to make the release process easily done and reproducible. There are tasks here that can be automated and that is the next step. There are places where I have to go back to the beginning or to do a new Pre-Release tag step. > > I now seek guidance and further enlightenment, especially from @Aleks, as the release manager for the past three years. > > Thanks, > James >
