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:

   1. Inform the dev list at least 2 weeks in advance that a tag is coming
   for a release with a specific date.
   2. 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.
   3. Do a pre-release tag and auto generated the changeset
   4. 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.
      1.  Look at those Jira Tickets that have been closed and fixed since
      the last release.
      2. 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.
      3. 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.
      5. Check any open Security issues (open CVEs) and kick off any
   required process there.
   6. Push the tag as a Release (no longer "pre-release"), also download
   the code assets and push that code snapshot to SVN draft release
   7. 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.
   8. After at least 72 hrs, tally votes for the release, describe the
   votes in detail.
   9. Move from SVN draft to SVN release on Apache Infra
   10. 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

Reply via email to