You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Manoj VM <ma...@fynarfin.io> on 2022/11/13 21:31:05 UTC
[FINERACT] [PROPOSAL] Minor version release
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
Re: [FINERACT] [PROPOSAL] Minor version release
Posted by James Dailey <ja...@gmail.com>.
Thanks Manoj - great explanation.
+1 (binding) on the concept.
Once we have this discussed, we should document this clearly on Confluence
pages
https://cwiki.apache.org/confluence/display/FINERACT/Release+Management
Which, I think have not been updated in a long while and are a bit out of
date.
& since this is highly related to this thread: any takers on that task?
Also, for clarity, the project is still responsible for the patch release,
so any voting has to follow our normal thing there.
Step #5, found here ==>
https://cwiki.apache.org/confluence/display/FINERACT/How+to+Release+Apache+Fineract
<https://cwiki.apache.org/confluence/display/FINERACT/How+to+Release+Apache+Fineract>
But again Manoj - great initiative and thank you.
jdailey
On Mon, Nov 14, 2022 at 5:23 AM Ed Cable <ed...@mifos.org> wrote:
> 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 <bg...@mifos.org> 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 <an...@yahoo.com.invalid>
>> 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 <
>>> manoj@fynarfin.io> 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
> edcable@mifos.org | 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>
>
>
Re: [FINERACT] [PROPOSAL] Minor version release
Posted by Ed Cable <ed...@mifos.org>.
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 <bg...@mifos.org> 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 <an...@yahoo.com.invalid>
> 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 <
>> manoj@fynarfin.io> 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
edcable@mifos.org | 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>
Re: [FINERACT] [PROPOSAL] Minor version release
Posted by Bharath Gowda <bg...@mifos.org>.
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 <an...@yahoo.com.invalid>
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 <
> manoj@fynarfin.io> 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
>
>
Re: [FINERACT] [PROPOSAL] Minor version release
Posted by Anu Omotayo <an...@yahoo.com.INVALID>.
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 customers1.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 <ma...@fynarfin.io> 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