Thanks Piotr, first I want to wait for Alex response. If he agree that releasing with Maven is all we need, then I think the process is just focus on complete maven distribution and then I'll do a 0.9.7 release to prove all is ok and we are in the good track.
Crossing fingers, since that would mean we get streamlined the process with all the benefits that will mean for all of us and our users :) Thanks El dom., 17 nov. 2019 a las 16:03, Piotr Zarzycki (< [email protected]>) escribió: > Cool. Good luck! - I look forward to that option working as in Ant. > > Try release process first before you will be too far and we end up again > with inability to release sdk for half a year. > > niedz., 17 lis 2019 o 15:58 Carlos Rovira <[email protected]> > napisał(a): > > > Hi Piotr, > > > > in the first email of this thread I exposed that "with-distribution" > > profile was the only thing still not completed (is doing the exact same > > process as pre changes), but this coming week is one of the thing in my > > priority since with that complete we will finish maven completely. > > > > So yes, still we can't build SDK with maven but hope to solve this in > > around a week with Chris help. > > > > Thanks > > > > > > El dom., 17 nov. 2019 a las 15:32, Piotr Zarzycki (< > > [email protected]>) escribió: > > > > > 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>* > > > > > > > > > -- > > Carlos Rovira > > http://about.me/carlosrovira > > > > > -- > > Piotr Zarzycki > > Patreon: *https://www.patreon.com/piotrzarzycki > <https://www.patreon.com/piotrzarzycki>* > -- Carlos Rovira http://about.me/carlosrovira
