Re: [VFS] 2.1 clirr report

Has anyone looked at whether the changes really do affect BC? Note that the Maven Clirr does not distinguish between source compat and BC. Breaking source compat is not as serious an issue. For example, the new methds in various interfaces don't affect BC:

Re: [VFS] 2.1 clirr report

Hello, I will/would vote for releasing 2.1 even when there are some minor problems (if it is well documented). Because I do see a large number of bugs for 2.0 and those users wont easily profit from a 3.0 (and I dont think backporting or removing of all incompatibilities will happen). Having

Re: [VFS] 2.1 clirr report

So, just call 2.1 instead 3.0? Fine by me. Package name becomes o.a.c.vfs3? ArtifactId becomes (variants of) commons-vfs3? Please confirm, Gary. I don't think we need to expound any more about why compatibility is important. No one has even presented any such argument. Let's stick to action

Re: [VFS] 2.1 clirr report

Let's look at this from a different POV: 1) If we release 2.1 as is, we are creating a risk. We are strictly speaking breaking BC. 2) If we release trunk as 3.0 with a package and Maven coordinate change, then there is zero risk. If you want to use the new version, you MUST change your imports.

Re: [RESULT}[VOTE] Release Validator 1.5.1 based on RC2

And thanks to Sebb for shepherding another release ;-) Gary On Fri, Apr 29, 2016 at 12:04 PM, sebb wrote: > The 72 hours elapsed some while ago. > > The following votes have been seen: > > Binding +1: > Sebastian Bazley > Emmanuel Bourg > Gary Gregory > Jörg Schaible > >

Re: [VFS] 2.1 clirr report

Hah, thanks for the details, Ralph. I will be sure to bring myself up to speed. That being said: I would still like to get some consensus from those who will be voting from the PMC on what should be done, given the current report (since my opinion and thus vote are non-binding :D)

Re: [VFS] 2.1 clirr report

FWIW, these discussions are not new. You might enjoy reading these threads - http://www.mail-archive.com/user@commons.apache.org/msg03711.html. But maybe not! ;-) Ralph > On Apr 29, 2016, at 12:43 PM, Ralph Goers wrote: > >> >> On Apr 29, 2016, at 10:57 AM,

Re: [VFS] 2.1 clirr report

> On Apr 29, 2016, at 10:57 AM, Josh Elser wrote: > > > > Ralph Goers wrote: >>> On Apr 29, 2016, at 9:27 AM, Josh Elser wrote: >>> >>> sebb wrote: On 29 April 2016 at 16:19, Josh Elser wrote: > sebb wrote: >> On 29

[RESULT][VOTE][ALL] (lazy consensus) Commons Parent 40 based on RC3

72 hours has elapsed without any negative votes so the lazy vote passes. I will publish the sources and send the announce shortly. On 25 April 2016 at 18:00, sebb wrote: > Third try: > > The Apache Commons Parent POM provides common settings for all Apache > Commons

[RESULT}[VOTE] Release Validator 1.5.1 based on RC2

The 72 hours elapsed some while ago. The following votes have been seen: Binding +1: Sebastian Bazley Emmanuel Bourg Gary Gregory Jörg Schaible There were no other votes. As there were at least 3 binding +1 votes and no -1 votes, the vote passes. Thanks to all who voted and for the feedback.

Re: [VFS] 2.1 clirr report

Ralph Goers wrote: On Apr 29, 2016, at 9:27 AM, Josh Elser wrote: sebb wrote: On 29 April 2016 at 16:19, Josh Elser wrote: sebb wrote: On 29 April 2016 at 15:59, Josh Elserwrote: How does changing the package name help?

Re: [VFS] 2.1 clirr report

> On Apr 29, 2016, at 9:27 AM, Josh Elser wrote: > > sebb wrote: >> On 29 April 2016 at 16:19, Josh Elser wrote: >>> sebb wrote: On 29 April 2016 at 15:59, Josh Elser wrote: >> How does changing the package name help? Doesn't

Re: [VFS] 2.1 clirr report

sebb wrote: On 29 April 2016 at 16:19, Josh Elser wrote: sebb wrote: On 29 April 2016 at 15:59, Josh Elser wrote: How does changing the package name help? Doesn't that just push a NoClassDefFound error instead of some missing implementation for a

Re: [VFS] 2.1 clirr report

On 29 April 2016 at 16:19, Josh Elser wrote: > sebb wrote: >> >> On 29 April 2016 at 15:59, Josh Elser wrote: >>> >>> > How does changing the package name help? Doesn't that just push a >>> > NoClassDefFound error instead of some missing implementation for

Re: [VFS] 2.1 clirr report

sebb wrote: On 29 April 2016 at 15:59, Josh Elser wrote: > How does changing the package name help? Doesn't that just push a > NoClassDefFound error instead of some missing implementation for a new > method? That means we change ALL the package names and the Maven

Re: [VFS] 2.1 clirr report

On 29 April 2016 at 15:59, Josh Elser wrote: > How does changing the package name help? Doesn't that just push a > NoClassDefFound error instead of some missing implementation for a new > method? That means we change ALL the package names and the Maven coords. Effectively it's

Re: [patch] Add elserj to KEYS

Thanks, sebb. That did the trick. sebb wrote: Try again. I added you to the commons unix group On 29 April 2016 at 05:03, Josh Elser wrote: Can someone add my key to https://dist.apache.org/repos/dist/release/commons/KEYS, please? It would appear that I lack the required

Re: [VFS] 2.1 clirr report

How does changing the package name help? Doesn't that just push a NoClassDefFound error instead of some missing implementation for a new method? Where do you all define what is public API (and thus what is stated to be stable)? Gary Gregory wrote: We have 2 choices IMO: document breaks or

Re: [VOTE] Release Validator 1.5.1 based on RC2

+1 Built from source using tarball with my complete compiler zoo. However, tests fail for JDK 9 (tested even with latest from today): = %< Failed tests: CalendarValidatorTest.testDateTimeStyle:197 validate(A) default CalendarValidatorTest.testFormat:215

Re: [VFS] 2.1 clirr report

We have 2 choices IMO: document breaks or change package name. The later is safer from a jar hell POV. The question is how likely are the changes going to break BC IRL? There are two main use cases: user like call sites and implementors of providers. Thoughts? Gary It looks like there are about

Re: [VOTE] Release Validator 1.5.1 based on RC2

On Apr 29, 2016 2:38 AM, "sebb" wrote: > > On 28 April 2016 at 18:34, Gary Gregory wrote: > > Note a blocker: Missing text in @link: > > I assume you mean "Not a blocker" above? Yes, not a blocker. > > > * Note: the {@link #isValid(String)} and {@link

Early Access builds of JDK 9 b116 & JDK 9 with Project Jigsaw b115 (#4909) are available on java.net

Hi Benedikt, Early Access b116 for JDK 9 is available on java.net, summary of changes are listed here . Early Access b115 (#4909) for JDK 9 with Project Jigsaw is

Re: [patch] Add elserj to KEYS

Try again. I added you to the commons unix group On 29 April 2016 at 05:03, Josh Elser wrote: > Can someone add my key to > https://dist.apache.org/repos/dist/release/commons/KEYS, please? It would > appear that I lack the required karma. > > Thanks in advance. > > - Josh > >

Re: CP 40?

"It will close after April 29 17:00 UTC" I made a mistake with the date calculation; it should have been Apr 28. But I thought I would honour the date in mail. On 28 April 2016 at 23:23, Gary Gregory wrote: > Did we give up on releasing CP 40? > > Gary > > -- > E-Mail:

Re: [VOTE] Release Validator 1.5.1 based on RC2

On 28 April 2016 at 18:34, Gary Gregory wrote: > Note a blocker: Missing text in @link: I assume you mean "Not a blocker" above? > * Note: the {@link #isValid(String)} and {@link } methods strip off any > leading > > +1 > > Release notes, MD5, SHA1, ASC, all OK. > >

Re: [crypto] The standard indentation is 4 spaces per indent

>This is Commons, AND this is brand new code, so in my mind there is no "original" formatting style to respect. 4 spaces per indent like the rest of the project please. Remember that Commons is a SINGLE project. Hopefully we won't have to argue about too much about this... [Uma] Thanks Gary for

RE: [crypto] The standard indentation is 4 spaces per indent

OK. Let's use 4 spaces indent. Thanks folks for sharing your opinion. -Original Message- From: Gary Gregory [mailto:garydgreg...@gmail.com] Sent: Friday, April 29, 2016 1:18 PM To: Commons Developers List Subject: Re: [crypto] The standard indentation is 4 spaces