I like this discussion, since I see potential to improve things. However it would be better to discuss this on a separate thread :-)
Thanks! 2015-01-12 16:01 GMT+01:00 Gary Gregory <garydgreg...@gmail.com>: > On Mon, Jan 12, 2015 at 9:56 AM, James Carman <ja...@carmanconsulting.com> > wrote: > > > Well, for my personal stuff, it just pushes to a "staging" repo (at > > Nexus OSS). The site stuff, we'd have to work through (maybe to a > > staging site?). Admittedly, my workflow is much simpler, but these > > things can be automated. We can't be the first people to have these > > type of requirements. > > > > Well, the Commons release process is a giant PITA IMO and could be made > better. But, IMO, some of the problems come from the requirements > themselves, which we've given ourselves, like releasing to both Maven and > to dist folders. > > Gary > > > > > > On Mon, Jan 12, 2015 at 9:46 AM, Gary Gregory <garydgreg...@gmail.com> > > wrote: > > > On Mon, Jan 12, 2015 at 9:13 AM, James Carman < > > ja...@carmanconsulting.com> > > > wrote: > > > > > >> Well, if you guys are comfortable with that, that's fine, but I've cut > > >> hundreds if not thousands of releases using the "push button" approach > > >> and it works out pretty well (most of the time). I actually use > > >> Jenkins to do my releases. > > > > > > > > > How does this button work? Does Jenkins deploy to both the Maven repo > and > > > the dist folders? And publishes the site? > > > > > > Gary > > > > > > > > >> If the push-button process isn't working > > >> smoothly, I'd take the time to fix that as opposed to throwing the > > >> baby out with the bath water. > > >> > > >> On Sun, Jan 11, 2015 at 11:16 AM, Phil Steitz <phil.ste...@gmail.com> > > >> wrote: > > >> > On 1/11/15 5:25 AM, James Carman wrote: > > >> >> Why is any of this being done manually? > > >> > > > >> > So we know what we are doing and so we can inspect tags and > > >> > artifacts. The "push one button" mutate tags approach is not > > >> > appealing to many of us. Every Commons RC I have ever cut, and > > >> > hopefully will ever cut follows the pattern: > > >> > > > >> > 0) Get source in shape for release > > >> > 1) Create a tag > > >> > 2) Inspect the tag > > >> > 3) If the tag is good, commit it > > >> > 4) Do a clean checkout of the tag and create the source distro and > > >> > any convenience binaries from the tag > > >> > 5) Inspect the artifacts > > >> > 6) If the artifacts are good, publish them for VOTE > > >> > > > >> > Trying to skip steps 2) - 4) via "automation" takes control away > > >> > from the RM and results in stressful revert / cleanup activities > > >> > when we screw up (which we all do regularly). The inspection steps > > >> > are all steps you end up taking anyway, so "push one button" doesn't > > >> > actually save any time. > > >> > > > >> > Phil > > >> >> > > >> >> On Sunday, January 11, 2015, Benedikt Ritter <brit...@apache.org> > > >> wrote: > > >> >> > > >> >>> 2015-01-11 11:03 GMT+01:00 Luc Maisonobe <l...@spaceroots.org > > >> >>> <javascript:;>>: > > >> >>> > > >> >>>> Le 10/01/2015 19:51, Benedikt Ritter a écrit : > > >> >>>>> Hi all, > > >> >>>>> > > >> >>>>> we have fixed the issues which where found in RC2 (and a lot > more > > >> ;-)) > > >> >>> so > > >> >>>>> I'd like to call a new vote to release Apache Commons Validator > > 1.4.1 > > >> >>>> based > > >> >>>>> on RC3. > > >> >>>>> > > >> >>>>> Changes between RC2 and RC3: > > >> >>>>> - Removed dependency to methods > Java 1.4 > > >> >>>>> - [VALIDATOR-342] URLValidator returns false for > > >> http://example.rocks > > >> >>>>> - [VALIDATOR-235] UrlValidator rejects url with Unicode > > characters in > > >> >>>>> domain label or TLD > > >> >>>>> - [VALIDATOR-339] URLValidator fails validating domain names > with > > a > > >> >>>>> trailing period, which are valid. > > >> >>>>> - [VALIDATOR-306] DomainValidator accepts labels longer than 63 > > chars > > >> >>> and > > >> >>>>> domain name lengths exceeding 255 chars > > >> >>>>> - [VALIDATOR-349] TLD tables should be pre-sorted > > >> >>>>> - [VALIDATOR-290] Create new url validation using rfc3986 and > IDN > > - > > >> >>> added > > >> >>>>> new test > > >> >>>>> - [VALIDATOR-350] Should "x.root" validate as a domain name? > > Removed > > >> >>>> "root" > > >> >>>>> from TLD list. Also "um" and "yu" as they are currently "Not > > >> assigned" > > >> >>>>> - [VALIDATOR-308] Logical errors in util.Flags affecting check > of > > >> >>>> multiple > > >> >>>>> flags as well as flag 64 > > >> >>>>> - [VALIDATOR-344] AbstractCheckDigit class does not fully test > > >> invalid > > >> >>>>> strings. Fix up the testCalculateInvalid() invalid method to > allow > > >> for > > >> >>>>> either invalid checksum or syntax (CheckDigitException) error > when > > >> >>>> testing > > >> >>>>> the entries in the invalid array. > > >> >>>>> - [VALIDATOR-297] Punycode url is not valid. Top-level domain > > regex > > >> >>>>> matching was wrong; did not allow embedded "-" as per RFC2396 > > >> >>>>> - [VALIDATOR-334] UrlValidator: isValidAuthority() returning > true > > >> when > > >> >>>>> supplied authority validator fails > > >> >>>>> - [VALIDATOR-309] UrlValidator does not validate uppercase URL > > >> schemes > > >> >>>>> - [VALIDATOR-343] Doc URL update for broken link > > >> >>>>> > > >> >>>>> Changes between RC1 and RC2: > > >> >>>>> - [VALIDATOR-307] - isValid checks if the given address is only > > IPV4 > > >> >>>>> address and not IPV6 > > >> >>>>> - [VALIDATOR-347] - toLowerCase() method is Locale-sensitive and > > >> should > > >> >>>> not > > >> >>>>> be used > > >> >>>>> - [VALIDATOR-348] - Update TLD list to latest version (Version > > >> >>>> 2014123000) > > >> >>>>> - [VALIDATOR-336] - CUSIPCheckDigit thinks invalid CUSIP is > valid. > > >> >>>>> - [VALIDATOR-345] - ISINCheckDigit fails to reject invalid > > >> >>> (non-numeric) > > >> >>>>> check digits > > >> >>>>> - [VALIDATOR-346] - SedolCheckDigit fails to reject invalid > > >> >>> (non-numeric) > > >> >>>>> check digits > > >> >>>>> - Removed STATUS.html > > >> >>>>> - Added README.md to binary and source distribution > > >> >>>>> - Fixed encoding of source files in build by setting > > commons.encoding > > >> >>>>> property > > >> >>>>> - Fixed JIRA report to contain the issues of the project > > >> >>>>> - Reverted dependency to commons-beanutils to 1.8.3 since this > is > > the > > >> >>>>> latest JDK 1.4 compatible release > > >> >>>>> - Added JDK requirements to release notes. > > >> >>>>> > > >> >>>>> Validator 1.4.1-RC2 is available for review here: > > >> >>>>> https://dist.apache.org/repos/dist/dev/commons/validator/ > (svn > > >> >>>> revision > > >> >>>>> 7682) > > >> >>>>> > > >> >>>>> The tag is here: > > >> >>>>> > > >> >>>>> > > >> >>> > > >> > > > http://svn.apache.org/repos/asf/commons/proper/validator/tags/VALIDATOR_1_4_1_RC3/ > > >> >>>>> (svn > > >> >>>>> revision 1650789) > > >> >>>>> > > >> >>>>> Maven artifacts are here: > > >> >>>>> > > >> >>>>> > > >> >>> > > >> > > > https://repository.apache.org/content/repositories/orgapachecommons-1076/commons-validator/commons-validator/1.4.1/ > > >> >>>>> Details of changes since 1.4 are in the release notes: > > >> >>>>> > > >> >>> > > >> > > > https://dist.apache.org/repos/dist/dev/commons/validator/RELEASE-NOTES.txt > > >> >>>>> I have tested this with JDK 1.6, 1.7 and 1.8 using maven 3.2.5. > > >> >>>>> > > >> >>>>> Site (some links my be broken but will be fixed when the site is > > >> >>>> deployed): > > >> >>>>> http://people.apache.org/~britter/validator-1.4.1-RC3/ > > >> >>>>> > > >> >>>>> Clirr Report: > > >> >>>>> > > >> >>>> > > >> > http://people.apache.org/~britter/validator-1.4.1-RC3/clirr-report.html > > >> >>>>> RAT Report: > > >> >>>>> > > >> >>> > > http://people.apache.org/~britter/validator-1.4.1-RC3/rat-report.html > > >> >>>>> Keys: > > >> >>>>> https://www.apache.org/dist/commons/KEYS > > >> >>>>> > > >> >>>>> Please review this release candidate and vote. > > >> >>>>> This vote will close no sooner than 72 hours from now, i.e. > after > > >> >>>>> 2015/01/04 19:00CET > > >> >>>> Since the vote started on January 10th, I suppose the real > closing > > >> date > > >> >>>> should be January 13th, not January 4th ;-) > > >> >>>> > > >> >>>>> [ ] +1 Release these artifacts > > >> >>>>> [X] +0 OK, but... > > >> >>>> One problem is that the MANIFEST.MF file in the binaries jar > > >> >>>> does not contain the build number. The corresponding entry reads: > > >> >>>> > > >> >>>> Implementation-Build: UNKNOWN_BRANCH@r??????; 2015-01-10 > > >> 18:25:42+0000 > > >> >>>> > > >> >>>> It has probably been built from a non-svn checkout. > > >> >>>> > > >> >>>> As binaries are only a convenience, I don't think it's a blocker, > > >> >>>> hence my +0. > > >> >>>> > > >> >>> Hello Luc, > > >> >>> > > >> >>> I usually do a svn export of the tag before I create the > artifacts. > > >> This > > >> >>> seems to be the wrong procedure, so all releases I've created will > > have > > >> >>> this problem :-( > > >> >>> I'll do a svn co from now on. > > >> >>> > > >> >>> Thanks! > > >> >>> Benedikt > > >> >>> > > >> >>> > > >> >>>> Luc > > >> >>>> > > >> >>>>> [ ] -0 OK, but really should fix... > > >> >>>>> [ ] -1 I oppose this release because... > > >> >>>>> > > >> >>>>> I'd like to add that all thanks for this RC goes to sebb, who > has > > >> >>>> invested > > >> >>>>> a lot of time to get this right. > > >> >>>>> Thanks! > > >> >>>>> > > >> >>>>> Benedikt > > >> >>>>> > > >> >>>>> > > >> >>>> > > >> >>>> > > --------------------------------------------------------------------- > > >> >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> >>> <javascript:;> > > >> >>>> For additional commands, e-mail: dev-h...@commons.apache.org > > >> >>> <javascript:;> > > >> >>>> > > >> >>> > > >> >>> -- > > >> >>> http://people.apache.org/~britter/ > > >> >>> http://www.systemoutprintln.de/ > > >> >>> http://twitter.com/BenediktRitter > > >> >>> http://github.com/britter > > >> >>> > > >> > > > >> > > > >> > > > >> > > --------------------------------------------------------------------- > > >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> > For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > >> For additional commands, e-mail: dev-h...@commons.apache.org > > >> > > >> > > > > > > > > > -- > > > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > > > Java Persistence with Hibernate, Second Edition > > > <http://www.manning.com/bauer3/> > > > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > > > Spring Batch in Action <http://www.manning.com/templier/> > > > Blog: http://garygregory.wordpress.com > > > Home: http://garygregory.com/ > > > Tweet! http://twitter.com/GaryGregory > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > -- > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org > Java Persistence with Hibernate, Second Edition > <http://www.manning.com/bauer3/> > JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> > Spring Batch in Action <http://www.manning.com/templier/> > Blog: http://garygregory.wordpress.com > Home: http://garygregory.com/ > Tweet! http://twitter.com/GaryGregory > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
