commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject Re: [VOTE] Release commons-dbutils 1.6 based on RC1
Date Tue, 04 Jun 2013 15:33:38 GMT
On Mon, Jun 3, 2013 at 9:25 PM, William Speirs <> wrote:

> I would like to release commons-dbutils 1.6
> commons-dbutils 1.6 RC1 is available for review here:
> (svn
> revision r1489259)
> Details of changes since 1.5 are in the release notes:
> The tag is here:
> Site:

You should post the whole site, not just the Javadoc. We can then look at
all the reports.

> Votes, please.  This vote will close in 72 hours
>   [ ] +1 Release these artifacts
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> For what it's worth, I expect this RC to fail as I feel confident I
> did something wrong in the release process. The steps I followed I
> documented here:

There is also

> If someone with experience release versions of commons software could
> walk me through how to do this properly I'd greatly appreciate it. I'd
> even be willing to update the documentation found here:
> For me, and maybe I'm alone on this, I simply find all of the bits and
> pieces that go into a release confusing and complicated: run this
> maven command, then copy these files to your home directory, then do
> something with Nexus (not even sure what that is), then delete those
> files from Nexus because it uploaded too much, then God forbid you
> want to change something after it was tagged. Why can't we have a few
> manual steps (make changes to code, change version in pom, done) and
> then a script that will generate the RC (doing all the copying and
> building, etc) and another to actually package and push the final
> release? I realize my contributions to commons are minimal, but I
> could see myself doing more if cutting RCs and pushing final releases
> were easier. Thoughts? Am I alone on this?

Our release process sucks, there is no doubt about that. The only thing we
can do within the current process is improve the documentation and keep it
up to date.

I'm sure I'm not the only one who would enjoy a less error-prone process.


> Thanks!
> Bill-
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

E-Mail: |
Java Persistence with Hibernate, Second Edition<>
JUnit in Action, Second Edition <>
Spring Batch in Action <>

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