Re: last paragraph: thanks Michael; this clarifies a couple of questions I had left... and I agree with an earlier date for release 1.5.0 (and following)... otherwise it'll also be too much work for anyone who wants to upgrade from a previous version.
Will add the gist of this conversation to the release document. Thanks again On Wed, Aug 26, 2020 at 12:24 AM Michael Vorburger <[email protected]> wrote: > On Wed, Aug 26, 2020 at 12:20 AM Aleksandar Vidakovic < > [email protected]> wrote: > >> Hi Michael, >> >> ... I'm almost there... my release task generates also GPG signatures for >> verification (tested them... all correct). >> > > cool! > > >> Only thing that is left is to include the generated API client JAR; at >> the moment only the sources are created, but no JAR artifact is available. >> Any idea how to proceed here (as this is a release I guess we shouldn't >> include just the client sources)? >> >> All details here: https://issues.apache.org/jira/browse/FINERACT-1129 >> (contains also link to sources) >> > > I'll engage (and answer above re. client) on that JIRA. > > >> Cheers >> >> On Tue, Aug 25, 2020 at 9:30 PM Aleksandar Vidakovic < >> [email protected]> wrote: >> >>> Alright Michael... the first list it is (WAR, server and client JAR, and >>> README). I'll create a PR for the Gradle task. >>> >>> One more question: I intend to git cherry pick features from develop >>> that arrived after I created the release branch... is that OK or do you >>> guys usually use different approaches (like rebase)? >>> >> > Either is fine with me personally, but I think the real question here is > more another one: > > Do you want to cherry-pick very selectively just a limited few particular > last minute changes, or just rebase to catch up with everything on develop. > The latter would in practice really mean that we just branched too soon? > ;-) Personally I probably would therefore go for the former (and > cherry-pick, only). > > There's always more coming in, and that's fine. Can't stop progress. You > just draw a line in the sand somewhere. There will always be the next > release after. Maybe we can have a 1.5.0 sooner after 1.4.0 than we had > after 1.3.0? :) Otherwise we'll never release... ;-) > > A related interesting question is perhaps if YOU (as the RM) should be the > one that raises PR for such cherry-picks. I would argue that you shouldn't > have to... you "did your job" of the process. You've sent the heads up > email, and nobody objected to the timeline you've proposed. Now I > personally would probably just let any contributors who still absolutely > WANT to get anything into 1.4.0 last minute raise PRs for the 1.4.0 branch > themselves (and resolve conflicts, if any; and get them to build). > https://github.com/apache/fineract/pull/1272 was a great working example > of that; as a committer to the project, you can Rebase Merge those yourself > in the future (if they are also on develop; I suggest that we do not put > anything on 1.4.0 that isn't ALREADY in develop; and NOT the other way > around, else it can quickly get very confusing IMHO) . > > BTW you could perhaps capture a summary of this discussion / conclusion on > https://cwiki.apache.org/confluence/display/FINERACT/How+to+Release+Apache+Fineract, > if you like. > > >> On Tue, Aug 25, 2020 at 7:48 PM Michael Vorburger <[email protected]> >>> wrote: >>> >>>> On Tue, 25 Aug 2020, 19:04 Ed Cable, <[email protected]> wrote: >>>> >>>>> Nazeer and Shruthi, are you able to provide some input on this thread >>>>> based on your experiences leading the release process before. >>>>> >>>>> Thanks, >>>>> >>>>> Ed >>>>> On Tue, Aug 25, 2020, 09:45 Aleksandar Vidakovic < >>>>> [email protected]> wrote: >>>>> >>>>>> Hi Michael, >>>>>> >>>>>> ... I think I saw a release script mentioned somewhere, but don't see >>>>>> it anywhere in the repo. >>>>>> >>>>>> I can put such a release task together for Gradle (aka >>>>>> "distribution")... >>>>>> >>>>> >>>> Yes, that would be really helpful, IMHO! I would be happy to try it out >>>> and peer review a PR from you about this, if you would like. >>>> >>>> that's not too complicated. Just to list the artifacts again: >>>>>> >>>>>> - WAR >>>>>> - server JAR >>>>>> - client JAR >>>>>> >>>>>> SGMT, and let's throw in the /README.md, and whatever else the 1.3.0 >>>> dist included? >>>> >>>> How about: >>>>>> >>>>>> - Kubernetes related YAML files >>>>>> >>>>>> I wouldn't, because technically that's not even "1.4.0" - it will >>>> pull :latest from Docker Hub.. we should deal with that "separately & >>>> later" (if ever), IMHO. >>>> >>>>> >>>>>> - should we add maybe add the Docker Compose file so that people >>>>>> can try out Fineract immediately (without installing a separate MySQL >>>>>> instance) >>>>>> >>>>>> I also wouldn't, because that won't actually work, because it builds >>>> from source, which won't be in *binary.tar.gz; sorting that out seems >>>> like a separate future task (new JIRA?), to me. >>>> >>>> Cheers, >>>>>> >>>>>> Aleks >>>>>> >>>>>> On Tue, Aug 25, 2020 at 4:41 PM Michael Vorburger <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Aleks, I was struggling to understand how you'll actually be >>>>>>> building the apache-fineract-1.4.0-binary.tar.gz and >>>>>>> apache-fineract-1.3.0-src.tar.gz archives for distribution on >>>>>>> http://fineract.apache.org... I was assuming that we had a script >>>>>>> or (much better) even directly a Gradle task for it in Fineract, but I >>>>>>> couldn't actually find anything like it on git. >>>>>>> >>>>>>> >>>>>>> https://cwiki.apache.org/confluence/display/FINERACT/How+to+Release+Apache+Fineract, >>>>>>> surprisingly, doesn't actually speak to that - or am I just not seeing >>>>>>> it? >>>>>>> Hoping someone who was involved in past releases may be able to clarify >>>>>>> here. >>>>>>> >>>>>>> If we never had that, and used to "manually cobble together" these >>>>>>> distributions in the past (huh?), then I think it would be great to see >>>>>>> a >>>>>>> PR contributing this. It would be the first step towards more >>>>>>> https://issues.apache.org/jira/browse/FINERACT-876 (later). >>>>>>> >>>>>>> I was looking for it to suggest that we include not only the *.war >>>>>>> but now also the new server *.jar as well as the very recent client >>>>>>> *.jar. >>>>>>> >>>>>>> On Tue, Aug 25, 2020 at 9:10 AM Aleksandar Vidakovic < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> @Ed Cable <[email protected]> >>>>>>>> going through yesterday's emails from Michael et al. to see what >>>>>>>> recent changes have to be included in the 1.4.0 ... had a couple of >>>>>>>> power >>>>>>>> outages here yesterday. Thanks for the pointers to work that has been >>>>>>>> done >>>>>>>> on the community app... good to have this on the radar. >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> On Mon, Aug 24, 2020 at 6:52 PM Ed Cable <[email protected]> wrote: >>>>>>>> >>>>>>>>> James, >>>>>>>>> >>>>>>>>> Thanks for bringing up the need for QA. The Mifos Community App UI >>>>>>>>> should be relatively in sync with the Finerat 1.4 changes and I've >>>>>>>>> put the >>>>>>>>> call out for manual QA on Michael's fineract.dev server on the >>>>>>>>> Mifos dev lists since a couple week back at >>>>>>>>> >>>>>>>>> Francis, Bharath, Sangamesh, Chirag, Alex from Habile, and some of >>>>>>>>> our GSOC interns have been involved in the QA thus far at >>>>>>>>> https://discourse.mifos.org/t/pull-request-review-and-qa-for-mifos-x-20-08-release/9671 >>>>>>>>> >>>>>>>>> The corresponding tickets at a UI level that complement the >>>>>>>>> Fineract release are being tracked at: >>>>>>>>> https://github.com/openMF/community-app/projects/6 or by >>>>>>>>> following this milestone on Github: >>>>>>>>> https://github.com/openMF/community-app/milestone/1 >>>>>>>>> >>>>>>>>> Francis nicely summarized the QA he's done to date in this Google >>>>>>>>> Doc: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://docs.google.com/document/d/1_6kjJxUasLaaZakStDSMKUXw2oqfWt90hzPMuEOFxrE/edit?usp=sharing >>>>>>>>> >>>>>>>>> @Aleksandar Vidakovic <[email protected]> Thank you again >>>>>>>>> for taking up the role of release manager. I do think that although it >>>>>>>>> would push the release out a couple more days we should continue >>>>>>>>> doing some >>>>>>>>> remaining manual QA this week. There are also two important tickets >>>>>>>>> that >>>>>>>>> Avik from Fynarfin is aiming to have fixes for by Thursday to go into >>>>>>>>> this >>>>>>>>> release: https://issues.apache.org/jira/browse/FINERACT-629 and >>>>>>>>> https://issues.apache.org/jira/browse/FINERACT-1120 >>>>>>>>> >>>>>>>>> With the release branch available, we're deploying it locally to >>>>>>>>> some users as well who are testing it in their development >>>>>>>>> environments. >>>>>>>>> >>>>>>>>> Ed >>>>>>>>> >>>>>>>>> On Sun, Aug 23, 2020 at 1:00 PM Aleksandar Vidakovic < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> I've added a note on >>>>>>>>>> https://cwiki.apache.org/confluence/display/FINERACT/How+to+Release+Apache+Fineract >>>>>>>>>> about the manual testing. FYI >>>>>>>>>> >>>>>>>>>> On Fri, Aug 21, 2020 at 7:52 PM Aleksandar Vidakovic < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi James, >>>>>>>>>>> >>>>>>>>>>> ... alright... noted. A bit new to the release game here so the >>>>>>>>>>> requirement to manually test slipped through the cracks. But maybe >>>>>>>>>>> August >>>>>>>>>>> might also not be the best of months for a release; responses to the >>>>>>>>>>> various release announcements on the mailing list were a bit scarce. >>>>>>>>>>> >>>>>>>>>>> Having said that: someone wants to help out with QA as James >>>>>>>>>>> mentioned? I'll give it a run on my machine, but would be great if >>>>>>>>>>> we get a >>>>>>>>>>> couple more people to verify. >>>>>>>>>>> >>>>>>>>>>> Speaking of manual testing - maybe we could do this a bit less >>>>>>>>>>> manual... I wanted to propose this already for a while and didn't >>>>>>>>>>> get to >>>>>>>>>>> it: https://gatling.io/ >>>>>>>>>>> >>>>>>>>>>> So technically Gatling is a load testing tool, but it has a >>>>>>>>>>> feature called Gatling Recorder ( >>>>>>>>>>> https://gatling.io/docs/current/http/recorder/) that allows you >>>>>>>>>>> to record all interaction between browser (read: community app) and >>>>>>>>>>> Fineract. That way we could get those test scenarios once recorded >>>>>>>>>>> and just >>>>>>>>>>> include them in the build as some kind of integration test. The >>>>>>>>>>> beauty of >>>>>>>>>>> this is that maintenance doesn't require any coding, just run a >>>>>>>>>>> specific >>>>>>>>>>> scenario again in your browser; could even replace the current >>>>>>>>>>> integration >>>>>>>>>>> tests in Fineract that should - I guess - cover more or less UI >>>>>>>>>>> scenarios, >>>>>>>>>>> but are currently a bit neglected. >>>>>>>>>>> >>>>>>>>>>> Please ping here on the list if you want to help out. We can >>>>>>>>>>> coordinate then for the final release date (I guess that won't be >>>>>>>>>>> Monday). >>>>>>>>>>> >>>>>>>>>>> Thanks again for the help James. >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Aleks >>>>>>>>>>> >>>>>>>>>>> On Fri, Aug 21, 2020 at 7:20 PM James Dailey < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Alex, >>>>>>>>>>>> >>>>>>>>>>>> I would like to see and understand the steps we need to take w >>>>>>>>>>>> regard to quality assurance (QA). It is vital that we have enough >>>>>>>>>>>> test >>>>>>>>>>>> coverage. If we don't have that, then we may need to hold off on >>>>>>>>>>>> the >>>>>>>>>>>> release until we do. >>>>>>>>>>>> >>>>>>>>>>>> In previous releases we always relied heavily on users going >>>>>>>>>>>> through each user interface screen to identify bugs. There were >>>>>>>>>>>> even bug >>>>>>>>>>>> finding rewards. This was true for the decade + that the code >>>>>>>>>>>> lived as >>>>>>>>>>>> Mifos. >>>>>>>>>>>> >>>>>>>>>>>> Since the Mifos front end UIs (multiple) are not yet at the >>>>>>>>>>>> same development state, I believe we need to make sure that test >>>>>>>>>>>> coverage >>>>>>>>>>>> is adequate at the unit level and end to end level. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps other devs could tell is what has been done to ensure >>>>>>>>>>>> the QA is there. >>>>>>>>>>>> >>>>>>>>>>>> If there are additional testing needs, let's also make sure we >>>>>>>>>>>> have jira tickets for those. >>>>>>>>>>>> >>>>>>>>>>>> If the Mifos UIs on the Mifos dev branches are tracking w this >>>>>>>>>>>> 1.4 release exactly, then perhaps that can be used for the testing >>>>>>>>>>>> here. >>>>>>>>>>>> >>>>>>>>>>>> QA should also include a look at any security issues that were >>>>>>>>>>>> solved. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> @jdailey >>>>>>>>>>>> >>>>>>>>>>>> On Fri, Aug 21, 2020, 5:42 AM Aleksandar Vidakovic < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi Everyone, >>>>>>>>>>>>> >>>>>>>>>>>>> As previously announced, I've just created the release branch >>>>>>>>>>>>> for our upcoming 1.4.0 release. >>>>>>>>>>>>> >>>>>>>>>>>>> You can continue working and merging PRs to the develop branch >>>>>>>>>>>>> for future releases, as always. >>>>>>>>>>>>> >>>>>>>>>>>>> The DRAFT release notes are on >>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/FINERACT/1.4.0+-+Apache+Fineract. >>>>>>>>>>>>> Does anyone see anything missing? >>>>>>>>>>>>> >>>>>>>>>>>>> Does anyone have any last minute changes they would like to >>>>>>>>>>>>> see cherry-picked to branch 1.4.0, or are we good to go and >>>>>>>>>>>>> actually cut >>>>>>>>>>>>> the release based on this branch as it is? >>>>>>>>>>>>> >>>>>>>>>>>>> I'll start the final stage of actually creating the release in >>>>>>>>>>>>> 3 days (Monday, August 24) if nobody objects. >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> >>>>>>>>>>>>> Aleks >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> *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> >>>>>>>>> >>>>>>>>
