Chris and Carlos, please actually produce a wiki page with the list of Maven 
commands.  I'm sorry, but don't think it will be as amazingly simple as you 
stated.  So do it!  Maybe Chris first to document the steps in a wiki page, 
then Carlos next to prove that Chris didn't miss anything in the documentation. 
 Also, please make sure that the parameters used to produce the artifacts 
includes the plugins and options for creating a reproducible binary.  Don't 
worry about if it actually matches anything right now.  I think I've explained 
why that is on another thread.

Like I said, the test is that the staging repo will have the same set of files 
as the 0.9.6 release (other than any new SWCs and with a different version 
number.

I think there will be more commands than just release:prepare and 
release:perform, calling set-property on things.  It is a lot of typing for the 
RM, prone to typing errors, which is why it was automated in Ant scripts and CI 
steps.

I would actually love to be wrong about this, because then I think we could 
reduce the set of CI steps to match as well.  As I've written many times, most 
of the CI steps just do the minimum Maven commands to build the release 
artifacts using the Maven poms we had in the past.

So go for it, and let us know when the final list of Maven commands is ready.

Don't worry about the Ant artifacts either for now.  Just get the Maven staging 
repo ready.  The Ant steps already know how to pull the Maven source artifact 
from staging and build the Ant artifacts.  I'm still unclear why it will ever 
make sense to drive that portion from Maven.  I have yet to see a technical 
explanation of how we can validate that Ant can use the build.xml files to 
create the Ant artifacts without actually running Ant, but that can wait until 
after we get the set of Maven commands for the Maven artifacts first.

Thanks,
-Alex

On 3/26/20, 1:26 AM, "Carlos Rovira" <carlosrov...@apache.org> wrote:

    Hi,
    
    that's amazingly simple, so I think we should go that way without doubt. I
    think reached this point there's a clear sense of that we need to go that
    route.
    
    We tried our best to stick with the previous process and we're all
    loosing lots of time. Then currently seems no more people in the community
    was interested in this thread, event to comment a single line (here or in
    the other users list thread), what means that or there's no more people
    like us in this project or people really is not interested and just want us
    to release and go forward.
    
    As previously I think most of the PMCs here (Om, Josh, Greg and me for
    sure), probably Yishay for his concise comments are more for this.
    My thinking is that the right now I think only 2 PMCs are for CI Server,
    and other one that is uncertainly but didn't try the CI Server.
    
    I think all can live together while is not a must for the rest that don't
    want it the others option, so what's about if we release with the
    super-simple steps Chris proposal, and others wanting to use CI do that
    when is their RM turn ? (of course maintaining it and making it work for
    his release without requiring nothing for the rest that doesn't want it).
    
    Release as other projects do is recommended but not required, the same as
    the actual CI server (but this one should be less recommended since is a
    royale-only practice not seen in any other place).
    
    What's the important thing is to release, do it, and do it easily and often.
    
    Thanks
    
    
    
    El jue., 26 mar. 2020 a las 8:24, Christofer Dutz (<
    christofer.d...@c-ware.de>) escribió:
    
    > Ok,
    >
    > I'll write this a last time as I do feel like we're going in circles and
    > will from now on not participate in any discussion involving releasing on 
a
    > CI server.
    >
    > A correct Maven release would use (There will be some additional profiles
    > to activate to include all modules)
    >
    > 1) the "mvn release:branch" call in order to create the branch and bump
    > the version of develop to the next version.
    > 2) the "mvn release:prepare" to change the pom to the release version, set
    > the timestamp in the pom (for reproducible builds) build ... if all tests
    > are good, commit the changes, tag this commit, update the poms to the next
    > development version, commit those changes and push everything.
    > 3) the "mvn release:perform" which will checkout the tagged version build
    > everything with the "apache-release" profile turned on (Which causes the
    > source.jars, Javadoc.jars, hashes and gpg singatures to be created as well
    > as the assembly) This also deploys the built artifacts to Nexus.
    >
    > Most of that you are already doing on the CI server however you're not
    > letting it do all automatically (For lack of credentials)
    >
    > But ... if you would just be doing those steps on the RM machine.
    >
    > Chris
    >
    >
    >
    >
    >
    > Am 26.03.20, 05:54 schrieb "Alex Harui" <aha...@adobe.com.INVALID>:
    >
    >
    >
    >     On 3/25/20, 4:46 PM, "Carlos Rovira" <carlosrov...@apache.org> wrote:
    >
    >         > What I want to know is what the Maven commands should be to
    > create a
    >         > release in this "conventional process" you are referring to.
    >         >
    >
    >         If you want to know what's the conventional maven process is, I
    > think I can
    >         ask Chris if he wants to work with me on that process, since he
    > already did
    >         many other Apache projects, we can expect the process is what is
    > needed for
    >         us to. But just expect that will be a series of standard maven
    > commands
    >         (prepare, release,...), so nothing strange at all (I expect).
    >
    >         Do you want us to do that?
    >
    >     Yes.  I want to know what the series of standard Maven commands are.
    > Then we can figure out how to convert them to run on the CI server.
    >
    >     -Alex
    >
    >         Thanks
    >
    >
    >         >
    >         > Maybe someone else can explain better than me.
    >         >
    >         > -Alex
    >         >
    >         > On 3/25/20, 2:22 PM, "Carlos Rovira" <carlosrov...@apache.org>
    > wrote:
    >         >
    >         >     Hi Alex,
    >         >
    >         >     El mié., 25 mar. 2020 a las 21:26, Alex Harui
    >         > (<aha...@adobe.com.invalid>)
    >         >     escribió:
    >         >
    >         >     > Carlos,
    >         >     >
    >         >     > I'm pretty sure that part of the "conventional process"
    > you want to
    >         > try
    >         >     > requires filling the staging repo from a local machine.
    >         >     >
    >         >
    >         >     This is what we already did. If you go to [1] will see [2].
    > That was
    >         > the
    >         >     upload of compiler to the staging repo. When trying to do
    > the same for
    >         >     typedefs it failed when trying to fill repo from local
    > machine. I think
    >         >     Chris or I should not take more time in trying to fix Ant
    > scripts that
    >         > are
    >         >     failing.
    >         >
    >         >     Thanks
    >         >
    >         >     [1]
    >         >
    > 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2F%23stagingRepositories&amp;data=02%7C01%7Caharui%40adobe.com%7C52c9a29e54a9447502a608d7d15f6d7e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637208080098996954&amp;sdata=u6gKxmAvurfd%2FeqZuuQKjQPjzhaQe8C2D9Y8H3muS90%3D&amp;reserved=0
    >         >     [2]
    >         >
    > 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimgur.com%2Fa%2Fw4az7pD&amp;data=02%7C01%7Caharui%40adobe.com%7C52c9a29e54a9447502a608d7d15f6d7e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637208080098996954&amp;sdata=n2yCWxI1vqrKMYihl3PtyEqNAwKjk9G24JQMhFJaiNY%3D&amp;reserved=0
    >         >
    >         >
    >         >
    >         >
    >         >     >
    >         >     > --
    >         >     > Carlos Rovira
    >         >     >
    >         >
    > 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C52c9a29e54a9447502a608d7d15f6d7e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637208080098996954&amp;sdata=8TI9LM0zCVzPV3NSeJRgEzmvyvMIfensPcK3l4mKWBo%3D&amp;reserved=0
    >         >     >
    >         >     >
    >         >     >
    >         >     >
    >         >
    >         >
    >         >
    >
    >         --
    >         Carlos Rovira
    >
    > 
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C52c9a29e54a9447502a608d7d15f6d7e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637208080098996954&amp;sdata=8TI9LM0zCVzPV3NSeJRgEzmvyvMIfensPcK3l4mKWBo%3D&amp;reserved=0
    >
    >
    >
    >
    >
    
    -- 
    Carlos Rovira
    
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fabout.me%2Fcarlosrovira&amp;data=02%7C01%7Caharui%40adobe.com%7C52c9a29e54a9447502a608d7d15f6d7e%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637208080098996954&amp;sdata=8TI9LM0zCVzPV3NSeJRgEzmvyvMIfensPcK3l4mKWBo%3D&amp;reserved=0
    

Reply via email to