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.
On Mon, Jan 12, 2015 at 9:46 AM, Gary Gregory <[email protected]> wrote: > On Mon, Jan 12, 2015 at 9:13 AM, James Carman <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >> wrote: >> >> >> >>> 2015-01-11 11:03 GMT+01:00 Luc Maisonobe <[email protected] >> >>> <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: [email protected] >> >>> <javascript:;> >> >>>> For additional commands, e-mail: [email protected] >> >>> <javascript:;> >> >>>> >> >>> >> >>> -- >> >>> http://people.apache.org/~britter/ >> >>> http://www.systemoutprintln.de/ >> >>> http://twitter.com/BenediktRitter >> >>> http://github.com/britter >> >>> >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: [email protected] >> > For additional commands, e-mail: [email protected] >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > -- > E-Mail: [email protected] | [email protected] > 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: [email protected] For additional commands, e-mail: [email protected]
