Ok, some initial thoughts on the release process specifically - Traditionally, we tie the source release with the Maven artifacts being released as one step - and we often don't bother voting on all the jars in Maven, since we trust that they're built from the source tag we are voting on anyway. We can optionally add validation of convenience artifacts (Maven artifacts, binary tarballs, etc) but definitely at first we'd skip that - all that is actually required as an ASF project is that we vote on the source.
We will move from Bintray to the Nexus repo at repository.apache.org (sorry, JFrog pals!) since that gives us full integration with the rest of the Apache projects' release process, and auto-syncing to Central. That's at least for now - we are currently doing pilot work for binary distribution of ASF projects via Bintray, but Maven repos are, by some combination of policy and tradition (I.e., I'm not sure how much is policy - "all ASF project's Maven artifacts must go through repository.a.o!" - and how much is just that we have repository.a.o, so hey, we'll use that), done through repository.a.o. I'll investigate our mid-term options on that front. The groupId is an interesting question. I *feel* like we shouldn't have to change them initially, but that may make it impossible to deploy through repository.a.o. I really think we should try to find a way to keep the existing groupIds until, say, 2.5.0 - I detest the idea of changing groupIds for point releases. I'll investigate on this front too. Binary distribution we can do however we want. That can stay as is for the time being as long as we can build against voted-on release tags. I'll dig into that more... A. On Friday, March 27, 2015, Andrew Bayer <[email protected]> wrote: > That'll definitely work for now - I'll start a separate thread on wiki > options going forward. > > A. > > On Friday, March 27, 2015, Cédric Champeau <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> wrote: > >> Ok since I prefer Asciidoctor over Confluence and that the Apache Wiki >> is... well; what is is, I implemented a simple wiki for Groovy [1]. TBH >> this is by far my favorite option, because you can use Asciidoctor locally >> to render, and it will integrate well with the website design. >> >> So the document about the release process is now rendered directly on the >> website [2]. If you want to update it, all you have to do is to edit the >> source [3] and submit a pull request. Once a PR is merged, it will take >> around 5 minutes for the site to be updated. Each "adoc" file in the >> "wiki" >> directory will automatically create a new file. >> >> Questions about the process welcome of course! >> >> NB: While nested directories in the wiki are supported, the rendered page >> have a problem with stylesheets, I will work later on this. >> >> [1] >> >> https://github.com/groovy/groovy-website/commit/f1678ab71734647b402c5374b5ae7ee051076bd1 >> [2] http://groovy-lang.org/wiki/groovy-release.html >> [3] >> >> https://github.com/groovy/groovy-website/blob/master/site/src/site/wiki/groovy-release.adoc >> >> >> 2015-03-27 8:11 GMT+01:00 Guillaume Laforge <[email protected]>: >> >> > Confluence preferred then >> > >> > 2015-03-27 2:51 GMT+01:00 Andrew Bayer <[email protected]>: >> > >> > > Not that I'm aware of... >> > > On Mar 26, 2015 17:11, "Emmanuel Lécharny" <[email protected]> >> wrote: >> > > >> > > > Le 26/03/15 21:20, Andrew Bayer a écrit : >> > > > > Ok - would Confluence be ok with everyone? I detest MoinMoin. =) >> > > > >> > > > Yuk :/ >> > > > >> > > > Any other option ? >> > > > >> > > >> > >> > >> > >> > -- >> > Guillaume Laforge >> > Groovy Project Manager >> > >> > Blog: http://glaforge.appspot.com/ >> > Social: @glaforge <http://twitter.com/glaforge> / Google+ >> > <https://plus.google.com/u/0/114130972232398734985/posts> >> > >> >
