Thank you for working on this process and documentation with Aleks. To clarify, I understand that voting is still required but this is a more expedited process than a normal release because it doesn't require that 2 week freeze/soak period correct?
+1 from me. Ed On Sun, Nov 13, 2022 at 11:38 PM Bharath Gowda <[email protected]> wrote: > Hi Manoj, > > I agree with you on the need for minor patch releases for the main release > versions as it helps a lot for organizations that are already using that > version in their live environment. > > +1 from my side > > Regards, > Bharath > Lead Implementation Analyst | Mifos Initiative > Skype: live:cbharath4| Mobile: +91.7019635592 > http://mifos.org <http://facebook.com/mifos> > <http://www.twitter.com/mifos> > > > On Mon, Nov 14, 2022 at 5:01 AM Anu Omotayo <[email protected]> > wrote: > >> Well done Manoj for this initiative, you have my +1 vote. >> >> Major versions supported and when support will end also needs to be >> looked into e.g >> >> Major versions 1.6.X and 1.7.X are in use on production by some customers >> 1.8.X has been released and is the current version >> >> When will support for 1.6.X and 1.7.X end? >> >> Regards >> Anu Omotayo >> >> >> On Sunday, November 13, 2022 at 10:31:29 PM GMT+1, Manoj VM < >> [email protected]> wrote: >> >> >> Hi Everyone, >> ... this is a continuation of the discussionAleksandar Vidakovic started >> some time before related to minor version releases >> >> 1. As we are constantly improving the Fineract with technology and >> functionality, each version is released with updates that take time >> to upgrade for existing users who are already live with a previous version. >> While they want to eventually move to the latest version they also want to >> do it at their will. ie, it is difficult for a user to upgrade to the >> latest version of Fineract just for minor fixes that are needed for their >> production to be stable. >> Hence it is a request from many Fineract users to have minor(patch) >> version releases on top of a Fineract release. >> For example, someone who is live on production with version 1.7.0 does >> not wish to upgrade to 1.8.0 or later just for a hotfix that is needed on >> version 1.7.0. It requires additional testing and effort and it is not >> feasible at the essence of time. Hence the hotfix should be provided as a >> patch ( minor) version release 1.7.1. >> >> 2. While we haven't done that before, it is not so difficult to have a >> minor version release. I was discussing this with Aleks and we have come up >> with the following approach to do the minor version release. The process >> can be as given below: >> 1. Minor version releases are not so different from normal releases, >> just that the waiting period for changes discussion is less because it is a >> minor change on top of an already approved release. The discussion on the >> PR happens on GitHub. >> 2. Voting is needed for the release. >> 3. Create a release branch from the previous version, and ask patch >> developers to send PRs to this branch. For example, for minor version >> release 1.8.1, the release branch 1.8.1 is created from the 1.8.0 tag >> 4. Once the minor version is released, the Release Manager has to >> merge this branch to develop to keep the develop branch updated, this can >> be done by creating a merge branch. >> 5. Sign and upload the minor version release to the Fineract website >> /SVN >> 6. Clean up by removing the branches created. >> >> Dear Members of the community, kindly vote for this process, and please >> provide your valuable feedback and suggestions. >> >> Thanks and Regards, >> Manoj >> >> -- *Ed Cable* President/CEO, Mifos Initiative [email protected] | Skype: edcable | Mobile: +1.484.477.8649 *Collectively Creating a World of 3 Billion Maries | *http://mifos.org <http://facebook.com/mifos> <http://www.twitter.com/mifos>
