Hi Alex, that's very good news! good luck with getting it :)
El vie., 10 abr. 2020 a las 7:08, Alex Harui (<aha...@adobe.com.invalid>) escribió: > Hi Carlos, > > I'm still back on getting compiler-build-tools 1.2.0 released. What was > posted on dist for compiler-build-tools was not complete, and I am trying > to get the CI server to do it using JGit because that is more secure, but > had to fix a JGit bug first. I hope the first 7 steps of the actual Royale > release go quickly once we get to that point. > > -Alex > > On 4/9/20, 12:28 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote: > > 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 (<aha...@adobe.com.invalid > >) > 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" <yishayj...@hotmail.com> 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:carlosrov...@apache.org> > > Sent: Thursday, April 2, 2020 6:47 PM > > To: Apache Royale Development<mailto:dev@royale.apache.org> > > 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 (<harbs.li...@gmail.com > >) > > 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 < > > christofer.d...@c-ware.de> > > > 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" <harbs.li...@gmail.com>: > > > > > > > > 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 < > > carlosrov...@apache.org> > > > 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 (< > harbs.li...@gmail.com>) > > > 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 < > > carlosrov...@apache.org> > > > >>> 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 (< > > > >>> christofer.d...@c-ware.de>) > > > >>>> 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" > > <aha...@adobe.com.INVALID>: > > > >>>>> > > > >>>>> 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%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243311339&sdata=kCFsrIpYZG9ZUk6hbZPaqtfGoIaVWjUo3ZBlfb98aNs%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%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243311339&sdata=zhSGBpwSbNGTi7hyxmt%2BEVqr7FB482WmDn8zK6NAicg%3D&reserved=0 > > > >>> > > > >>> > > > >> > > > >> -- > > > >> Carlos Rovira > > > >> > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243321295&sdata=EnH8GN7x4dM0ohQb7UIIX5TOoJE6A5u65y6Jb%2FnpGsI%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > -- > > Carlos Rovira > > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243321295&sdata=EnH8GN7x4dM0ohQb7UIIX5TOoJE6A5u65y6Jb%2FnpGsI%3D&reserved=0 > > > > > > > > > > -- > Carlos Rovira > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7C399c4801fe89479b1aa708d7dc57a179%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637220141243321295&sdata=EnH8GN7x4dM0ohQb7UIIX5TOoJE6A5u65y6Jb%2FnpGsI%3D&reserved=0 > > > -- Carlos Rovira http://about.me/carlosrovira
