Let’s keep the Ant part of the release as it’s been. Please. If you have ways to improve the Maven part of the release, that’s fine. I don’t think anyone has an issue with it, but we’ve discussed Ant releases and the consensus is that we should keep Ant releases for the Ant build. There’s no reason to rehash this for every release.
Thanks, Harbs > On Mar 17, 2020, at 9:49 PM, Carlos Rovira <[email protected]> wrote: > > Hi Alex, > > I don't think you should be upset, don't think that to be a positive way to > discuss this task, since in that way you force a solution and maybe not all > of us think the same way as you. So although it could cause some tiring to > all of us (me included) I think we need to put all our effort to get to > some point where we all be satisfied. > > This is probably the most problematic task we have in Royale, and since is > difficult to solve and seems there are at least two groups of people > thinking in different ways, we need to get what's the better way to solve > it. No one way of thinking is better that other you have valid points (but > in the same way I can find arguments against them), but don't think that is > a productive route. I want to spend our times in get a real solution. > > The CI steps you did was a great effort and very appreciated. I was very > happy when you made it, since from outside it all sound very promising. > Then IIRC Piotr's release doesn't was as straight as expected. So I think > that was a point we should all take into account. Then my experience > updating maven and broken some steps was as well something from what we > should learn and think about it. I tried to fix them without exit. I still > want to improve Maven even more in the future. One of the problem I see is: > If we fix CI steps, will broke again when new changes in maven will be > done? probably...and will the fix as difficult as now? In my experience, > probably too. > > Don't think as well that is good for this discussion impose a way to act. > I'll be fixing CI steps if I could, but I repeat that I tried during some > days without exit. Spend many hours over it. So is not something I'd not > do, is just that the process is very fragile and is not what I expect it > will bring to us. Each thing we change can break it and that's a huge > problem ahead. Or is just me the only one that see a huge problem on this?. > > Instead, I can offer my work in fixing in other way that I think is more > "industrial" or proven, but you don't like it, due to the points you > express (that I repeat can be valid, but I see that all are totally > surmountable If we work in a more industrial way to solve it. Don't think > we are more special that other hundreds of projects out there, and all of > that projects just use maven for release. > > Maven SDK could still not be 100%, that's right, but is one of the things > we need to fix in the actual process I offer. For sure. And releasing that > way, you still can build with ANT and check it was all right. We don't need > to do at the same time that releasing. I think that's a valid point. > > I think that if you defend the CI steps in such fixed way, the rest of us > thinking that's not the way to go can just not oppose, but you can't ask us > to be responsible of trying to solve something that is very (very) > difficult to solve, since maybe we just can't do it. You must take into > account that new changes could come (to ant, to maven), and working that > way should be your responsibility or the any others here that think in that > way. I can help or support in the way I can, but maybe limited in some way. > And of course, we should all know that new optimizations to build systems > can't be stopped to defend a concrete way to release. IOW, release is a > process to "publish for other", and we can't block progress in the project > or in the way we build to support a concrete way of release. > > just my 2 > > Carlos > > > > > > El mar., 17 mar. 2020 a las 19:50, Harbs (<[email protected] > <mailto:[email protected]>>) escribió: > >> +1 >> >> Harbs >> >>> On Mar 17, 2020, at 8:10 PM, Alex Harui <[email protected]> >> wrote: >>> >>> I’m sorry, but these repeated attempts to try to use Maven too much just >> make me very upset. This was a concern of mine when two people who have >> never produced a release went off to refactor the process. There is theory >> and reality. The reality is that Maven cannot and should not be used to >> streamline our release process because: >>> >>> - We've learned over the years that RMs have trouble getting set up >> correctly. >>> - We've learned over the years that RMs have trouble uploading Maven >> artifacts to repository.a.o. >>> - We should know that the only way to validate the Ant Task in the >> release artifacts is to use Ant to verify it. >>> >>> Those are the three main reasons there are multiple release steps on the >> CI server. I am hopeful that the new Maven builds can cut down on one or >> two steps, or maybe just make those steps more straightforward, but the >> process simply cannot just run Maven's release steps on the RM's local >> computer. It must run on the CI server, and that requires stopping from >> time to time to verify and sign stuff. >>> >>> A fourth reason was that the Ant script had proven to be able to build >> an IDE-compatible artifact. I am not 100% convinced that the Maven >> distribution build can exactly replicate that artifact. But again, if an >> Ant user wants to use Ant to create artifacts for some IDE to test local >> changes, then we need to prove in each release that Ant can produce that >> set of artifacts for the IDE. So now that Maven can supposedly do the >> same, it actually adds more work to the verification process. The Maven >> artifacts for an IDE will need to be compared against the Ant-produced >> artifacts for an IDE. >>> >>> In short, we should use Maven to produce Maven artifacts, and Ant to >> produce Ant artifacts so that the RM is verifying the artifacts long before >> the voters have to. And make it all work on a CI server so that RM's don't >> have to deal with system setup, and not have upload issues blow up the >> process. >>> >>> I also am not a fan of using Maven to do scripting, especially if it >> involves custom mojos/plugins. That's what scripting tools like Ant are >> for. The goal should be to make the release system maintainable by >> everyone, not just by experts in Maven. Similarly, the Ant steps do not >> use custom plugins/tasks for the same reason. >>> >>> Use Maven to build the Maven artifacts. Use Ant to build the Ant >> artifacts and sequence the steps. Use the CI server. Verify and sign >> locally. These are the requirements. It was all working and we could have >> released every month. I think it is your responsibility to make it work >> again within those constraints. >>> >>> My 2 cents, >>> -Alex >>> >>> On 3/17/20, 8:48 AM, "Carlos Rovira" <[email protected] >>> <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>>> wrote: >>> >>> Hi >>> >>> this morning in the slack Apache Royale official channel Chris Dutz >> asked >>> about plans for release 0.9.7. If you see Greg and I help him to >> create an >>> Apache Royale interface for pulling data from a Consumer in an IoT >> Apache >>> PLC4X app. Something very cool :). He published a tweet with a video >>> showing it. >>> >>> So regarding the release, I explain that I spent many days some >> months ago >>> trying to fix the CI release steps to release, but I was unable to do >> it. I >>> think making changes to the Maven o Ant make the 13 steps very >> fragile and >>> difficult to fix. And we need to evolve continually Maven and Ant, so >> that >>> means a huge task that will require an huge amount of time that almost >>> nobody here has. So I must say that although the work done on that >> front >>> was amazing and huge maybe we need to streamline it to an standard. I >> know >>> is difficult, but although we had many expectations put on the 13 step >>> release process, after try it seems that we finally are not getting >> what we >>> wanted, that is streamline the release process. >>> >>> This is one of the critical points that hold us to release 1.0, since >> not >>> having an easy way to release means as we push 1.0 and people tries >> us, >>> we'll need to be faster on releasing, and we can't wait 6 month or a >> year, >>> since that we'll mean user will not want that kind of release cycle. >>> >>> So here is my proposal to work on a release process that allow us to >>> release more often and more easily. Hope you all can consider it: >>> >>> First: We all know we want build with ANT and MAVEN. And when I refer >> to >>> "all" I really mean "all". Although I'm a Maven advocate, I really >>> appreciate the point to have ANT on place so having 2 build systems >> that >>> completely works mean advantage. In fact although I use maven I build >> with >>> both system daily. >>> >>> Second: Build does not mean Release. I think other times we discussed >>> Release as a way to impose Maven over Ant. Or maybe that was the >> perception >>> for others, but not my intention (and maybe not the intention of >> others). >>> But that's not the objective. Release [1] means to us just >> "publication >>> outside the development community, defined as individuals actively >>> participating in development or following the dev list." >>> >>> That means that we don't need to release using Maven and Ant at the >> same >>> time, we can streamline greatly the process to just releasing with >> Maven so >>> we can ensure a simple process the same as any other Apache project. >>> >>> It means that people trying the release need to check it with Maven, >> but >>> community users can continue using ANT or Maven to build or even just >>> download the SDK and use it on his IDE of choice and don't use ANT or >> Maven >>> at all. >>> >>> Third: The fact is the rest of projects I know all use releases and CI >>> based on Maven, and that should point us that maybe we're trying to >>> force something that is not standard in our industry, so if we want >> to make >>> it more reliable and easy process, is normal to embrace how others are >>> doing, since that does not mean we're throwing away a build system, >> since >>> per previous point we don't want to remove ANT. >>> >>> Finally, Chris and I offer our time to make the easiest release >> process we can >>> that let all of us release easily and often (maybe each 1-2 month?) >>> >>> Thanks >>> >>> >>> [1] >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0 >> >> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0> >> < >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0 >> >> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.apache.org%2Flegal%2Frelease-policy.html%23release-definition&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=8gWY67nvYiUF7svzTN2bychZHMGeqMGu0vtQHyEO85s%3D&reserved=0> >>> >>> -- >>> Carlos Rovira >>> >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0 >> >> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0> >> < >> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0 >> >> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&data=02%7C01%7Caharui%40adobe.com%7Ce48b38e3883e48a5bc0008d7ca8a91a3%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637200568817332809&sdata=y5ueVlWqrKYSx6dGpiOr3ytI1w%2Bg%2FNRE051IlACZ2EU%3D&reserved=0> >>> >> > > > -- > Carlos Rovira > http://about.me/carlosrovira <http://about.me/carlosrovira>
