Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: error (nike.apache.org: local policy)
MIME-Version: 1.0
Sender: jcarman@carmanconsulting.com
In-Reply-To: 
 <CACZkXPxqAZUW44JuTaXFGOduZCVb9t0Hd23=CaYEGWHtt+yG2Q@mail.gmail.com>
References: 
 <CAB917RKJUbRhSdgVLQoZWe7kBJ94Si007pyApY6xxCeE-uDuyw@mail.gmail.com>
	<54B24A57.2080306@spaceroots.org>
	<CAB917RKmkL8WrWUciAiWuaxj4jLQmFSgN_Nho0RaLSoS+F6K2A@mail.gmail.com>
	<CALznzY6D2Yn+wbXiu8BO4Lmq9VsMLrxsB33sioZGmgDMDQZ2XQ@mail.gmail.com>
	<54B2A1E3.8@gmail.com>
	<CALznzY7jHAQDYoTjvUeBY9f5c5eajHd3uwM8Tnrhr=f0bLaoaA@mail.gmail.com>
	<CACZkXPxZGW2vRVmMPRR65yy8Fcdsf_BbSjS62x+ATeu5hBqaHw@mail.gmail.com>
	<CALznzY4-EkgTkerWjnd6dCLtx7Kt934giYV5c4EtfeQ==PAuFA@mail.gmail.com>
	<CACZkXPxqAZUW44JuTaXFGOduZCVb9t0Hd23=CaYEGWHtt+yG2Q@mail.gmail.com>
Date: Mon, 12 Jan 2015 10:12:13 -0500
Message-ID: 
 <CALznzY7rTjo0gxzUkFB56YAAE-UO70Ueew=_aj19APAN61JzZg@mail.gmail.com>
Subject: Re: [VOTE] Release Aoache Commons Validator 1.4.1 based on RC3
From: James Carman <james@carmanconsulting.com>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001a11c341ac64cb19050c75ee99

--001a11c341ac64cb19050c75ee99
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Some of our requirements are self-imposed too.  We do have quite a bit of
freedom and autonomy as a PMC.  We have some wiggle room on some things
which may help.

On Monday, January 12, 2015, Gary Gregory <garydgregory@gmail.com> wrote:

> On Mon, Jan 12, 2015 at 9:56 AM, James Carman <james@carmanconsulting.com
> <javascript:;>>
> 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 <garydgregory@gmail.com
> <javascript:;>>
> > wrote:
> > > On Mon, Jan 12, 2015 at 9:13 AM, James Carman <
> > james@carmanconsulting.com <javascript:;>>
> > > wrote:
> > >
> > >> Well, if you guys are comfortable with that, that's fine, but I've c=
ut
> > >> hundreds if not thousands of releases using the "push button" approa=
ch
> > >> 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.steitz@gmail.com
> <javascript:;>>
> > >> 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 step=
s
> > >> > 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
> <javascript:;>>
> > >> wrote:
> > >> >>
> > >> >>> 2015-01-11 11:03 GMT+01:00 Luc Maisonobe <luc@spaceroots.org
> <javascript:;>
> > >> >>> <javascript:;>>:
> > >> >>>
> > >> >>>> Le 10/01/2015 19:51, Benedikt Ritter a =C3=A9crit :
> > >> >>>>> 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 Validato=
r
> > 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 6=
3
> > 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 onl=
y
> > IPV4
> > >> >>>>> address and not IPV6
> > >> >>>>> - [VALIDATOR-347] - toLowerCase() method is Locale-sensitive a=
nd
> > >> 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.tx=
t
> > >> >>>>> 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 read=
s:
> > >> >>>>
> > >> >>>>  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 blocke=
r,
> > >> >>>> 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 wi=
ll
> > 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:;>
> > >> >>> <javascript:;>
> > >> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> <javascript:;>
> > >> >>> <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
> <javascript:;>
> > >> > For additional commands, e-mail: dev-help@commons.apache.org
> <javascript:;>
> > >> >
> > >>
> > >> --------------------------------------------------------------------=
-
> > >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> <javascript:;>
> > >> For additional commands, e-mail: dev-help@commons.apache.org
> <javascript:;>
> > >>
> > >>
> > >
> > >
> > > --
> > > E-Mail: garydgregory@gmail.com <javascript:;> | ggregory@apache.org
> <javascript:;>
> > > 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-unsubscribe@commons.apache.org
> <javascript:;>
> > For additional commands, e-mail: dev-help@commons.apache.org
> <javascript:;>
> >
> >
>
>
> --
> E-Mail: garydgregory@gmail.com <javascript:;> | ggregory@apache.org
> <javascript:;>
> 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
>

--001a11c341ac64cb19050c75ee99--