Hi Carlos, Comments inline.
niedz., 17 lis 2019 o 12:43 Carlos Rovira <[email protected]> napisał(a): > Hi Alex, > > first of all I understand completely your concerns about this changes since > I now the time and work it cost to you. At the time you worked on this > there was not all this new maven enhancements that allow us to simplify > things. I strongly believe that all this changes can carry us a less > painful build and release process if we (mostly I, supported by Chris) can > overcome the CI changes to work with the new changes. All this will ease > things for people coming that should be other priority for us. I think this > is the main barrier for newcomers and making thing ultra easy can allow > more people coming to Royale. This is all a bet, that we think can reach a > good point. We we need to solve things in chunks if we want to succeed. > > But, I want to state clearly here, that if you finally don't see a good end > for this, you can veto this change and we can roll back to the previous > process. I think we can reach to simplify all and make releases more easy > to do, but it will imply in some parts changes that we need to agree that > can be done. For all this we need to try to be open mind. > > So instead of trying to expose ways to solve concrete parts already > exposed, I want to ask about how we can simplify the release process: > > We have Maven and ANT as first citizens for build process, so users can use > what they want. But my question here's, do we need to use both in the > release process? From what I understand Apache only requires us to use one > of them for releasing process. So we could just rely on the maven process > that are just few lines (already posted early in this thread). Copy here to > notice the simplicity: > > Ideally releasing a part of Royale is just a 2-3 step process: > > - royale-compiler: > - mvn release:prepare -DautoversionSubmodules=true > - mvn release:perform > - royale-typedefs: > - update the pom.xml: royale.compiler.version to the new released > version > - mvn release:prepare -DautoversionSubmodules=true > - mvn release:perform > - royale-asjs: > - update the pom.xml: royale.compiler.version and > royale.typedefs.version to the new released version > - mvn release:prepare -DautoversionSubmodules=true > - mvn release:perform > > > In doing in this way, we'll streamline the release process and will not > need to do anything more. Just that few lines. And that means hopefully > make our release process a more tiny process in time to all of us, while > users that wants to build with ANT can do it without problem. Can we agree > with this? Let me know if I'm wrong with this. Notice that my focus is to > try to get to the easiest way possible to build and release we can get. > > Does this few lines build IDE artifacts ? > To not create a very long thread. I'll left this here so we can see what > you guys think about it. > > Thanks in advance > > Carlos > > > > El dom., 17 nov. 2019 a las 0:06, Alex Harui (<[email protected]>) > escribió: > > > I'm pretty sure I added JGIT in order to do the release on the CI server. > > See change 1aa2b16 in royale-compiler on Feb 11, 2019. The reason the CI > > needs JGIT is because the regular Maven git support seemed to expect that > > you had a private key registered since most folks run the release plugin > on > > their private computer. JGIT allowed specification of username without > > password for commits. > > > > The Royale compiler is also required to parse the time stamps in order to > > inject them into the SWFs and SWCs. So I am hopeful that didn't break, > but > > if it did, you know where to look. Also the release steps on CI expect > the > > timestamp to be given by the RM so it can be used in Ant as well. So I > am > > concerned about that as well. But maybe it will work or you will fix it. > > I don't care as long as it doesn't cost me time. But as RM you are > > responsible for the Ant artifacts as well. The timestamp must also be > > handed to the voters as well in order for them to reproduce the same > > binaries. > > > > My experience was that zlika was very responsive to fixing an issue. I'm > > not sure if Maven has picked up all of the zlika changes, but if not, > then > > one of the artifacts will not reproduce. When I offered a patch to > Maven, > > I was told I had to go figure out their test harnesses and build a set of > > test cases, which I still haven't found time to do. Again, if it all > ends > > up working and doesn't cost me time, it doesn't matter which plugin we > use. > > > > My 2 cents, > > -Alex > > > -- > Carlos Rovira > http://about.me/carlosrovira > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
