+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]>> 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> > -- > 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>
