Thanks for starting off this discussion. I presume you’re mainly thinking of the Avatica process but all except 4 also apply to Calcite.
I’ve not personally run into 1, 2 or 3 but I can see how other people might. Feel free to update HOWTO if that would solve the problem. (Blame me for 2, especially. I introduced the “X.Y.Z” and “X.Y+1.Z-SNAPSHOT” notation, and it’s not helpful.) I don’t have an opinion about 4, because I’m not an expert on Docker and I’d never heard of WSL. Julian > On Jun 25, 2018, at 4:47 PM, Francis Chuang <[email protected]> wrote: > > I'd like to open up some discussion regarding the developer experience for > making releases. > > The maven configuration shipped with the project already does a lot of heavy > lifting and automation, but I ran into a few issues as a non-Java developer. > > Here are some of the things I ran into, while releasing Avatica 1.12. > 1. GPG signs using a default key (I think this is the first key, if no > default is set). I had multiple keys and my Apache key was not my first key. > 2. I was not 100% sure that `-DdevelopmentVersion` should be the version > after the current release. > 3. It took a while to work out how to authenticate against Apache's maven > repo. > 4. I did not have a suitable environment. OpenJDK did not install in WSL > correctly, while Oracle JDK did, but I think all releases should be built > using OpenJDK. I ended up spinning up an OpenJDK container using the > maven:alpine docker image and using it to execute the commands for building. > > For 1, I think it should be possible to pass in the key to be used in > `-Darguments` (will need to experiment). > For 2, I will update the documentation. > For 3, I will also update the documentation and reference > http://www.apache.org/dev/publishing-maven-artifacts.html#dev-env > For 4, I would like to propose adding docker-compose.yaml with a bash script > that will automate the different steps for executing the dry run, publishing > or the RC and the final build promotion in a docker image. This would be > extremely useful for releases to easily build and make releases (with safety > checks in place) to reduce the time needed to make releases drastically. This > does not replace the current "more manual" method of making releases, but > offers a second option for those who are not primary java developers. > > What do you think? > > Francis
