Hi Alex, don't understand the problem. Chris and I was able to reach step 7. The big problem is there with compiler generating classes with lines in different orders depending on OS (and probably JDK vendor). I think solving that will make you move from the problematic point. But don't understand that you have problems in steps 1 to 6.
El jue., 9 abr. 2020 a las 9:21, Alex Harui (<[email protected]>) escribió: > FWIW, I saw Royale_Compiler_Build_Tools_Release_Step_002 work. I'm done > for tonight. If anyone is bored, they can try to get the > Royale_Compiler_Build_Tools_Release_Step_002_Sign target to work in > compiler-build-tools/releasesteps.xml by renaming > Royale_Compiler_Build_Tools_Release_Step_003_Sign and fixing up the paths. > Otherwise I will start there tomorrow evening. > > -Alex > > On 4/8/20, 9:03 PM, "Yishay Weiss" <[email protected]> wrote: > > >sounds good :) > > Hi Carlos, > > This sounds like a good plan to me too. Alex and I will do our best to > get 0.9.7 out in April. Harbs will be in charge of releasing 0.9.8 in May, > and you will be in charge of releasing 0.9.9 in June. > > Are we still in agreement on that? > > Thanks, > Yishay > > From: Carlos Rovira<mailto:[email protected]> > Sent: Thursday, April 2, 2020 6:47 PM > To: Apache Royale Development<mailto:[email protected]> > Subject: Re: Royale Releases > > Hi Harbs, > > sounds good :) > > As well, I expect I can do 0.9.9 in June from my local machine with the > process we already exposed too :) > > Thanks > > Carlos > > > El jue., 2 abr. 2020 a las 15:50, Harbs (<[email protected]>) > escribió: > > > I spent over an hour with Alex on the Zoom last night trying to > understand > > all the different technical points. > > > > One point which became clear to me last night is that Ant and Maven > are > > distributed differently so there are points of failure that one has > which > > the other doesn’t. > > > > I also want to stress that Alex is actually a fan of Maven. > > > > We all want the Maven release to be easier, but somehow this is being > > conflated with bashing Ant. > > > > As far as I’m concerned, the steps forward are: > > > > 1. Yishay should work on releasing 0.9.7. > > 2. He will hopefully be supported by Alex, Chris and Carlos to make > it as > > smooth as possible. > > 3. When he’s done, I plan on sitting down with him to discuss his > > experience. > > 4. I plan on working on releasing 0.9.8 sometime in May. > > 5. While I’m working on 0.9.8 I expect to use Yishay’s experiences > as well > > as my own to try and understand as much about the process as I can > (Ant, > > Maven and NPM too). > > 6. I hope to work with anyone who wants to help to improve the > process as > > much as I can. > > > > Sounds OK? > > > > Harbs > > > > > On Apr 2, 2020, at 4:38 PM, Christofer Dutz < > [email protected]> > > wrote: > > > > > > Hi folks, > > > > > > I would say we have coverage for both maven ant equally as we're > > building the same code. > > > > > > However we are missing the important assertions. It's not that the > Ant > > build is running some tests Maven isn't. > > > It's just that the settings for Ant seem to be different than for > Maven > > and the Ant ones happen to work. > > > > > > Ideally there would be real tests that test the output of both to > see if > > it works in both cases. > > > > > > Chris > > > > > > > > > > > > Am 02.04.20, 15:15 schrieb "Harbs" <[email protected]>: > > > > > > Adding more coverage for Maven is good. > > > > > > Removing coverage for Ant is not. > > > > > > Do you agree? > > > > > >> On Apr 2, 2020, at 4:07 PM, Carlos Rovira < > [email protected]> > > wrote: > > >> > > >> Hi Harbs, > > >> > > >> I think what we're trying to say is that until now we released > with > > Maven > > >> and Ant, and that was hiding a flaw in Maven (SVG example). So > that > > means > > >> what we were trying to cover was not covered clearly, so the > premise is > > not > > >> right. > > >> > > >> > > >> > > >> El jue., 2 abr. 2020 a las 14:56, Harbs (<[email protected]>) > > escribió: > > >> > > >>> No one is arguing that we shouldn’t add more tests. > > >>> > > >>> Please let’s not make it seem like there’s a disagreement about > that. > > >>> > > >>>> On Apr 2, 2020, at 10:46 AM, Carlos Rovira < > [email protected]> > > >>> wrote: > > >>>> > > >>>> Hi Alex, > > >>>> > > >>>> first, many thanks for the detailed email. I'll comment on this > later > > as > > >>> I > > >>>> have more time. > > >>>> > > >>>> For now, to add up a recent example on what Chris commented: If > you > > all > > >>>> remember a week ago I was trying to use SVG Images in a blog > example > > that > > >>>> was published 2 days ago. Nobody tried SVG Images before > building with > > >>>> maven, I know that since maven was not properly configured and > using > > that > > >>>> component from Maven was failing with an RTE. Probably we have > more > > >>> things > > >>>> not working the same way when build from Maven and Ant, and > that's > > >>>> something that will need people using that code paths in test > > >>> applications > > >>>> (or in their own apps) to see if things works properly. > > >>>> > > >>>> I was recently introduced to "examples-integrationtest" by > Chris, > > that I > > >>>> plan to use soon as I can. I think is a great idea, since you > get a > > >>> Firefox > > >>>> running test interface of the real use of some concrete royale > code. I > > >>>> think passed until now unnoticed by all of us, and seems a > powerful > > tool. > > >>>> There's already an example about FlexStore with some basic > assertions. > > >>>> > > >>>> Again, thanks, and will comment on the rest later > > >>>> > > >>>> Carlos > > >>>> > > >>>> > > >>>> > > >>>> > > >>>> El jue., 2 abr. 2020 a las 9:20, Christofer Dutz (< > > >>> [email protected]>) > > >>>> escribió: > > >>>> > > >>>>> Hi Alex, > > >>>>> > > >>>>> just a point you are bringing up: "Code coverage". > > >>>>> > > >>>>> I strongly dislike the idea of "asjs" effectively being the > test for > > the > > >>>>> compiler. The reasoning behind this is: yes you do get more > code > > >>> covered, > > >>>>> but only the happy-path (ideally) and even if things go wrong, > the > > end > > >>>>> results aren't tested. Did add a module to asjs years ago > > >>>>> ("examples-integrationtest") that deployed the examples in a > tomcat > > >>> server > > >>>>> then opens a Firefox browser and clicks through 2 of the > examples (I > > >>> added > > >>>>> two dummy tests as an example, but seems no one touched this > after > > me). > > >>> I > > >>>>> did this because I remember us working on asjs for weeks > without > > anyone > > >>>>> noticing the compiler wasn't producing runnable code ... same > with > > the > > >>>>> little unit-tests that are still run for every example, that > simply > > >>> check > > >>>>> if an output is generated, because we had a prolonged period > of time > > >>> where > > >>>>> we were all working on different parts, but for quite some > time the > > >>>>> application compilation just didn't output anything and no one > > noticed. > > >>>>> > > >>>>> So coverage is nothing without assertions (my opinion) ... ok > ... > > it's > > >>>>> slightly better than no coverage, but not much, in my opinion. > > >>>>> > > >>>>> I think in parallel to this release discussions I have seen > numerous > > >>>>> threads about someone doing something that broke something for > > someone > > >>>>> else. This could be addressed by increasing coverage by > providing > > >>> explicit > > >>>>> tests. > > >>>>> > > >>>>> Coming back to the releases: > > >>>>> I have no objections, if you do a "release" locally and > automate the > > >>>>> validation on the CI server (Which effectively would be your > proposal > > >>> to do > > >>>>> the first 12 steps on local hardware and the 13th on the CI > server). > > I > > >>> even > > >>>>> think that's a good idea ... There could be one step for > building a > > >>> release > > >>>>> from a given "git tag" for every build system and generic > means to > > >>> compare > > >>>>> tar.gz and zips produced by any build system with that of > another > > >>> (ideally > > >>>>> with better output than just a plain "true/false"). This would > even > > >>> help to > > >>>>> iron out the last potentially existing bumps out of the Maven > > >>> distribution. > > >>>>> > > >>>>> Chris > > >>>>> > > >>>>> > > >>>>> > > >>>>> Am 02.04.20, 07:59 schrieb "Alex Harui" > <[email protected]>: > > >>>>> > > >>>>> Hi, > > >>>>> > > >>>>> This is my attempt to explain what goes into a release in > hopes that > > >>>>> we can understand and agree on what our release process is. It > > became > > >>>>> apparent in my reading of the wiki page with the new Maven > steps and > > in > > >>>>> talking with Harbs today that there are still many > misunderstandings > > >>> about > > >>>>> what we do to create a release. I don't generally like writing > > >>>>> instructions in English because it is easy to be ambiguous. > All of > > the > > >>>>> steps that we use to create releases had been captured in Ant > scripts > > >>> in a > > >>>>> much more explicit way, IMO, but I took the time to write them > down > > in > > >>>>> English here: > > >>>>> > > >>> > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Froyale-asjs%2Fwiki%2FTask-List-For-Royale-Releases&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=LEnt8RHhcRGzOkRz4JOCLeJrfBFNnD3Y6th4M51XUGE%3D&reserved=0 > > >>>>> > > >>>>> I did this quickly by scanning the CI steps, the new Maven > steps and > > >>>>> the Ant scripts used in prior releases so there could > certainly be > > >>> mistakes > > >>>>> and missed steps. If I did my math right, the RM for 0.9.7 > will > > have to > > >>>>> complete over 100 tasks (essentially, typing a command-line 100 > > times). > > >>>>> Future RMs, when we don't have to release build-tools, will > have > > about > > >>> 92 > > >>>>> steps. And I did not include voter verification checks the RM > should > > >>> run > > >>>>> before opening a vote (verifying that the artifacts download > and > > match > > >>>>> their checksums, etc). As an RM, I run a bunch of tests on > the RC > > >>> before > > >>>>> sending out the vote. Maybe we should add those to the task > list. > > >>>>> > > >>>>> I think there has been confusion about the use of Ant in the > release > > >>>>> process. Because I was the RM for the first set of > FlexJS/Royale > > >>> releases, > > >>>>> and I'm a lazy person who hates typing at the command line, I > created > > >>> Ant > > >>>>> scripts to execute these 100 steps. But I agree that it is > not a > > >>>>> requirement that other RMs must use the Ant scripts for these > > >>> commands. If > > >>>>> you are the RM and like typing, go ahead. > > >>>>> > > >>>>> Then we found out that other people couldn't get through this > task > > >>>>> list. I think the 3 people who tried were having trouble with > Maven > > >>>>> uploads and downloads. So what I did was put the first 40 > steps or > > so > > >>> into > > >>>>> Jenkins jobs. And by doing that, Piotr was able to produce > our last > > >>>>> release. And that also saves on manually typing commands. But > > again, > > >>>>> going forward, the RM gets to choose how they want to execute > these > > >>> steps. > > >>>>> > > >>>>> If you scan the set of steps, you'll see that "ant" is only > in there > > >>>>> once. I believe the recent threads have been about this single > > command > > >>> out > > >>>>> of the 100+ commands. This is why this has been so > frustrating to > > me. > > >>> I > > >>>>> believe there is a solid technical reason for that one > command: it > > >>> proves > > >>>>> that the build.xml files in the source packages can build the > .tar.gz > > >>> that > > >>>>> are useful to NPM and IDE users who use Ant and want to test a > > change. > > >>>>> > > >>>>> I think of it as code-coverage. If we had code-coverage > tools, we > > >>>>> would ask that the RM complete as much of the automated > code-coverage > > >>>>> testing as possible before posting the release for a vote. > That one > > >>>>> command increases our code coverage by running the build.xml > files. > > We > > >>>>> should be always working to increase automated code coverage > in the > > RC. > > >>>>> Certainly for me as RM, I will gladly watch TV as the > automated tests > > >>> run > > >>>>> because a failed RC means going back through many of the first > 25 > > >>> commands > > >>>>> again and wastes other people's time. Each RC is more emails > to read > > >>> and > > >>>>> more time from the voters and testers. > > >>>>> > > >>>>> If there are other ways for the RM to get the same or better > code > > >>>>> coverage on the build.xml files before posting the RC, we can > discuss > > >>> those > > >>>>> options. > > >>>>> > > >>>>> I am hopeful we can all agree on these simple principles: > Strive > > for > > >>>>> better code coverage and fewer failed RCs. Royale's main > purpose is > > to > > >>>>> save other people time. Let's do that in creating releases > too. > > >>>>> > > >>>>> One issue that was brought up recently was whether it is a > good > > >>>>> decision to have the RM test all of the build platforms we > support. > > >>>>> Suppose we add some other build system support or more in the > future? > > >>>>> Again, the code coverage principle applies here, but also, I > would > > like > > >>> us > > >>>>> to retain feature parity, and I also hope for as few RCs and > votes as > > >>>>> possible. So instead of having separate > votes/features/release-dates > > >>> for > > >>>>> the Maven artifacts vs the Ant artifacts vs the > SomeFutureBuildTech > > >>>>> artifacts, I think we should have one vote and keep them all > in sync. > > >>> If > > >>>>> we do ever get around to monthly or bi-monthly releases, I > think > > >>> separate > > >>>>> build platform releases would be too much work. > > >>>>> > > >>>>> But consider this thought I just had today: the RM doesn't > really > > >>>>> have to choose to do all 100 commands on a local machine or > with Ant > > >>>>> scripts or do the first 40 via CI. The RM can actually pick > and > > choose > > >>>>> commands to run on the CI server. The CI Jenkins jobs are not > a > > >>>>> separate/alternative release process, they are just another > way of > > >>>>> executing the first 40 steps. Using CI jobs actually requires > > >>> additional > > >>>>> command-line cut-and-paste to push commits on the CI server > and to > > sign > > >>> and > > >>>>> validate binaries locally, but that's the trade-off of not > having to > > >>>>> configure your machine to successfully run all of the > automated tests > > >>> and > > >>>>> build systems, and being able to run a command by filling in > the > > version > > >>>>> number and rc number and hitting the "ok" button instead of > making > > sure > > >>> you > > >>>>> got the whole command typed in correctly. > > >>>>> > > >>>>> So, an RM can run the first 25 steps locally, then go the CI > server > > >>>>> and run what is now Jenkins Job "Royale_Release_Step_013" (no > need to > > >>> run > > >>>>> the first 12) and it will run tasks 26 through 32, and if it is > > >>> successful, > > >>>>> then the RM has proven code coverage of the build.xml files. > (If the > > >>>>> resulting tar.gz and zips are not posted, then the RM should > verify > > that > > >>>>> they match the ones from Maven distribution). I would > encourage RMs > > to > > >>>>> also use the CI jobs that generate the emails to make sure the > > subject > > >>> and > > >>>>> content is correct and contains the usual instructions so we > have > > >>>>> consistency. Maybe someday there will be CI jobs to do the > last 60+ > > >>> steps > > >>>>> if that helps. We could add a Jenkins job that runs an Ant > build on > > RC > > >>>>> artifacts on dist.a.o as well. > > >>>>> > > >>>>> I would like you all to help maintain the list of 100 steps > and > > other > > >>>>> documents related to the release process, and improve the CI > jobs and > > >>> Ant > > >>>>> steps if it helps you be a more efficient RM. I am hopeful > that now > > >>> that I > > >>>>> have hopefully explained our release process better, that we > can see > > >>> that > > >>>>> these 100+ steps just have to be done in some way. The RM can > figure > > >>> out > > >>>>> what way works best for them, but they must get through all of > them. > > >>>>> > > >>>>> Thanks, > > >>>>> -Alex > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> -- > > >>>> Carlos Rovira > > >>>> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=OLKPLOkpOC%2FOO0kKKbnep8NyHwgrJUp5KGnLbtaDcYQ%3D&reserved=0 > > >>> > > >>> > > >> > > >> -- > > >> Carlos Rovira > > >> > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=OLKPLOkpOC%2FOO0kKKbnep8NyHwgrJUp5KGnLbtaDcYQ%3D&reserved=0 > > > > > > > > > > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C8d9d14f28b824df89c3a08d7dc3afa41%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220018172793191&sdata=OLKPLOkpOC%2FOO0kKKbnep8NyHwgrJUp5KGnLbtaDcYQ%3D&reserved=0 > > > > -- Carlos Rovira http://about.me/carlosrovira
