accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: Ease of making release candidates (was: Javadocs in binary "release")
Date Wed, 20 May 2015 22:10:59 GMT
On Wed, May 20, 2015 at 2:40 PM, Josh Elser <> wrote:
> A big issue that bothered me for 1.7.0 is the lack of clarity in how the
> maven-release-plugin interacts with our branching strategy. We talked about
> this on IRC (which I tried to capture[1] in a recent addition). How can we
> improve the complete RC picture there?

This is where I think being as close to "mvn release:prepare
release:perform" is valuable. For example, it's useful to understand
what "mvn release:prepare" actually does[2] regarding
commits/branches/tags, so one understands what to pay attention to
when double checking things. Likewise, it's useful to understand what
"mvn release:perform" does[3], so one understands what prerequisites
are necessary to configure for deploying to the staging repo.

We could go completely the other route, but I much prefer teaching
people to fish[4], because I think it enables them to adjust over time
as things change, especially when those changes occur in ways which
are hard to write a script resilient of. This would be changes like
the URL to the staging repo, or the minimum Maven version, or one's
git version, or when one has `make` linked to `cmake` instead of
`gmake`, etc. I think spreading the understanding also helps people
adjust to the nuances of their environment, rather than relying on
another developer's anticipation of everybody else's environment.
Maven already offers a framework for process reproducibility across
environments, so why wrap it?

Now that you know where I'm coming from, if others feel strongly that
it would be beneficial to automate some of this so that others can do
releases without calling maven or dealing with git
commits/branches/tags directly, I can volunteer to put some time into
creating such a script (perhaps while working with a 1.5.x and 1.6.x

> The other half of me wanting to fork off this convo is that there's also
> more to making a release than just making the release candidate. I probably
> had 30+ commits to CMS over the past week (granted some of which were me
> just editing content on CMS), but we have a lot of steps which are now just
> copying files from the release, committing to the site repo. I'd love to see
> more done for automation here that can reduce the pain for the post-RC work.

+0.5 to that. I'm willing to help a bit here, but it's a bit daunting,
and it's not even clear to me where we can automate, especially with
CMS being involved as a middle-man.

> [1]


View raw message