Carlos, Release steps provides also couple of more very useful stuff. Like creating branches on git, sending emails. - I hope your plan is to preserve all of that.
niedz., 17 lis 2019 o 16:16 Carlos Rovira <[email protected]> napisał(a): > 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 > -- Piotr Zarzycki Patreon: *https://www.patreon.com/piotrzarzycki <https://www.patreon.com/piotrzarzycki>*
