commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [VOTE] Release Aoache Commons Validator 1.4.1 based on RC3
Date Mon, 12 Jan 2015 14:13:08 GMT
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.  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.steitz@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 <britter@apache.org> wrote:
>>
>>> 2015-01-11 11:03 GMT+01:00 Luc Maisonobe <luc@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-unsubscribe@commons.apache.org
>>> <javascript:;>
>>>> For additional commands, e-mail: dev-help@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message