groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cédric Champeau <cedric.champ...@gmail.com>
Subject Re: Build/CI infrastructure etc
Date Fri, 27 Mar 2015 14:52:53 GMT
Right. It's honestly disappointing if we cannot keep as much as possible of
our current infra, a release of Groovy has 270+ files and changing the way
you deliver has direct implications on the build, so it will require a bit
of work to make sure we didn't break any artifact (Groovy has lots of
special handling because of variants of artifacts like jarjar'ed,
invokedynamic version and Android).

Regarding the groupId, even if we only start changing on 2.5, we have to
remember that we also maintain old branches of Groovy. Including 2.3 and
2.4, so it is possible (and almost certain) that we release a 2.4 release
after 2.5. Gradle for example still relies on 2.3 and cannot migrate
easily. And in general I think it's fair to our community to maintain
multiple branches like we did so far.

2015-03-27 15:15 GMT+01:00 Andrew Bayer <abayer@apache.org>:

> 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 <andrew.bayer@gmail.com> 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 <cedric.champeau@gmail.com
> > <javascript:_e(%7B%7D,'cvml','cedric.champeau@gmail.com');>> 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 <glaforge@gmail.com>:
> >>
> >> > Confluence preferred then
> >> >
> >> > 2015-03-27 2:51 GMT+01:00 Andrew Bayer <andrew.bayer@gmail.com>:
> >> >
> >> > > Not that I'm aware of...
> >> > > On Mar 26, 2015 17:11, "Emmanuel Lécharny" <elecharny@gmail.com>
> >> 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>
> >> >
> >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message