Re: [VFS] .jar named directories VFS-490

[Jörg Schaible]

Bernd Eckenfels wrote:

> Am 09.10.2013, 21:53 Uhr, schrieb Mark Fortner :
> 
>> In your previous posting about VFS-490 you mentioned not wanting to
>> browse
>> JAR files as though they were directories.  It would be nice if that was
>> configurable -- I actually use that functionality and find it pretty
>> useful.
> 
> Hm... no I do want to browse JAR files (or actually the VFSClassLoader
> wants to), but it tries to browse directories which are named name.jar/
> with the JAR overlay - which does not work. The opening of JAR files as
> filesystems is of course a usefull feature :)
> 
> I have seen Gary put some work into it, I have'nt been able to replicate
> his problems, yet.

Hehe, I wonder if something similar happens for other schemes following the 
pattern name.scheme pattern e.g. ./file.url/ ;-)

- Jörg


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

Re: [DISCUSS] Putting several unmaintained components to dormant

[Ate Douma]

On 10/10/2013 12:24 AM, Torsten Curdt wrote:

Every now and then I keep getting requests via private mail asking to
release javaflow as it seems to be working for people. Yet I know there is
still so much essential stuff to fix for a 1.0 release.

Crossing over to the other thread: I know on github I would made a 0.x
release already ages ago but knowing I won't have time to work on it
anymore I keep pushing this out at commons.


Wouldn't this be a case to allow and use intermediate milestone releases?

Using a 1.0-Mxx version would make still clear to the users things haven't 
settled yet (API wise), so should not limit or restrict making API changes 
before a final 1.0 release, but would help both the community and the project 
moving. More likely to incite further involvement and contributions, etc.


Being 'stuck' on getting a (final) 1.0 release out because everything should be 
settled and 'frozen' (API wise) first doesn't make sense to me at all.


"Release early and often" really is what keeps open source projects moving 
forward, *any* policy which blocks that is plain wrong and should be fixed.


Note: I'm not saying I'm against the strict versioning rules, but those should 
NOT block getting to a 1.0 release easily.

And I don't think they do. Isn't this where Milestone releases are meant for?

Ate



Release and put into dormant?
It's a strange situation.

cheers,
Torsten




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

Re: [DISCUSS] Putting several unmaintained components to dormant

[Jörg Schaible]

Hi,

Ate Douma wrote:

> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>> Every now and then I keep getting requests via private mail asking to
>> release javaflow as it seems to be working for people. Yet I know there
>> is still so much essential stuff to fix for a 1.0 release.
>>
>> Crossing over to the other thread: I know on github I would made a 0.x
>> release already ages ago but knowing I won't have time to work on it
>> anymore I keep pushing this out at commons.
> 
> Wouldn't this be a case to allow and use intermediate milestone releases?
> 
> Using a 1.0-Mxx version would make still clear to the users things haven't
> settled yet (API wise), so should not limit or restrict making API changes
> before a final 1.0 release, but would help both the community and the
> project moving. More likely to incite further involvement and
> contributions, etc.
> 
> Being 'stuck' on getting a (final) 1.0 release out because everything
> should be settled and 'frozen' (API wise) first doesn't make sense to me
> at all.

We should not be so afraid to switch to 2.x if the 1.x API turns out to be 
cumbersome in some cases. Typically you may also increase Java level in the 
meantime and therefore eventually even have a benefit of new possibilities.
 
> "Release early and often" really is what keeps open source projects moving
> forward, *any* policy which blocks that is plain wrong and should be
> fixed.
> 
> Note: I'm not saying I'm against the strict versioning rules, but those
> should NOT block getting to a 1.0 release easily.
> And I don't think they do. Isn't this where Milestone releases are meant
> for?

I am not a big fan of milestones unless we really have a forced schedule for 
the final release. If we get into the situation that the milestone is the 
latest release for months, we get into jar hell again, because that 
milestone is then *used* like any proper release. You cannot prevent this.

There is a reason why I have to use for a (private) Maven plugin an artifact 
like org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1. 
That's a result of such a "milestone" and I really like to avoid this 
situation for Apache Commons.

>> Release and put into dormant?
>> It's a strange situation.

No release it as 1.0 and go on with 2.x, since 1.0 is probably already based 
on old technology.

- Jörg


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

Re: [DISCUSS] Putting several unmaintained components to dormant

[Benedikt Ritter]

I like the idea of releasing 0.x versions. A good example is [csv]. I would 
have no problem with releasing the current trunk as 0.9. At the moment [csv] is 
just another component we don't releaese because we want to come up with a 
perfect API (and I take responsibility for that :-)

Benedikt

Send from my mobile device

> Am 10.10.2013 um 12:15 schrieb Jörg Schaible :
> 
> Hi,
> 
> Ate Douma wrote:
> 
>>> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>>> Every now and then I keep getting requests via private mail asking to
>>> release javaflow as it seems to be working for people. Yet I know there
>>> is still so much essential stuff to fix for a 1.0 release.
>>> 
>>> Crossing over to the other thread: I know on github I would made a 0.x
>>> release already ages ago but knowing I won't have time to work on it
>>> anymore I keep pushing this out at commons.
>> 
>> Wouldn't this be a case to allow and use intermediate milestone releases?
>> 
>> Using a 1.0-Mxx version would make still clear to the users things haven't
>> settled yet (API wise), so should not limit or restrict making API changes
>> before a final 1.0 release, but would help both the community and the
>> project moving. More likely to incite further involvement and
>> contributions, etc.
>> 
>> Being 'stuck' on getting a (final) 1.0 release out because everything
>> should be settled and 'frozen' (API wise) first doesn't make sense to me
>> at all.
> 
> We should not be so afraid to switch to 2.x if the 1.x API turns out to be 
> cumbersome in some cases. Typically you may also increase Java level in the 
> meantime and therefore eventually even have a benefit of new possibilities.
> 
>> "Release early and often" really is what keeps open source projects moving
>> forward, *any* policy which blocks that is plain wrong and should be
>> fixed.
>> 
>> Note: I'm not saying I'm against the strict versioning rules, but those
>> should NOT block getting to a 1.0 release easily.
>> And I don't think they do. Isn't this where Milestone releases are meant
>> for?
> 
> I am not a big fan of milestones unless we really have a forced schedule for 
> the final release. If we get into the situation that the milestone is the 
> latest release for months, we get into jar hell again, because that 
> milestone is then *used* like any proper release. You cannot prevent this.
> 
> There is a reason why I have to use for a (private) Maven plugin an artifact 
> like org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable-1. 
> That's a result of such a "milestone" and I really like to avoid this 
> situation for Apache Commons.
> 
>>> Release and put into dormant?
>>> It's a strange situation.
> 
> No release it as 1.0 and go on with 2.x, since 1.0 is probably already based 
> on old technology.
> 
> - Jörg
> 
> 
> -
> 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

[DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

[Ate Douma]

I've move this into a separate [DISCUSS] thread as I think it needs separate 
discussion.


Jörg gave some objections below about using Milestone releases, as I proposed 
earlier to support releasing intermediate versions of a not-yet-stabalized 
component.


While I understand his problems with unstable versions potentially getting 
'stuck' for long time, where end-users *might* start expecting them to remain 
stable, I don't agree this is, or should be, the common case. Or at least not an 
argument to hold against using such 0.x or -Milestone releases.


Instead, the whole point is to get project/component development moving *faster* 
by allowing *experimental* end-users to provide feedback, and more flexibility 
and convenience for the developers of such project/component.


The idea to have to 'switch' to a next major version for any incompatibile 
change, as Jörg proposes, requiring package changes, whatnot, while a project 
clearly is not ready to stabalize, really puts way too much hurdles up for both 
the developers *and* such experimental end-users, as they would HAVE to change 
all of their code to be able to provide AND leaverage such new 0.x or Milestone 
version.


Case in point: SCXML
If we are allowed to start working on this component shortly, we intend to, and 
HAVE to switch to a 1.0 version first, as there already is a 0.9 version release 
out, while we will need to move to newer JDK and incompatible API changes 
anyway. At the same time, getting a final/stabalized 1.0 release out most 
certainly will take several iterations.
I don't want to have to wait doing an intermediate release, nor rapidly having 
to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone releases are 
acceptable for this purpose. Where would Milestone releases [1] be useful for 
otherwise, anyway?


I think a real problem might arise IF other components (or 3rd party libraries) 
would start depending directly on such Milestone releases, potentially 
introducing unexpected instabilities for end-users. And maybe it is worthwhile 
to make such usages, at least for Commons, prohibited. That would make sense to me.


But for components like SCXML, javaflow, or csv, this I don't think would be a 
real issue. Those end-users making use of these experimental components are, or 
should be very well aware, of the added responsibility they take depending on a 
not-yet-stabilized version, as clearly is also indicated by the version, as well 
as SHOULD be prominently documented in the release notes, readme, etc.


Thoughts?

Ate

On 10/10/2013 12:45 PM, Benedikt Ritter wrote:

I like the idea of releasing 0.x versions. A good example is [csv]. I would 
have no problem with releasing the current trunk as 0.9. At the moment [csv] is 
just another component we don't releaese because we want to come up with a 
perfect API (and I take responsibility for that :-)

Benedikt

Send from my mobile device


Am 10.10.2013 um 12:15 schrieb Jörg Schaible :

Hi,

Ate Douma wrote:


On 10/10/2013 12:24 AM, Torsten Curdt wrote:
Every now and then I keep getting requests via private mail asking to
release javaflow as it seems to be working for people. Yet I know there
is still so much essential stuff to fix for a 1.0 release.

Crossing over to the other thread: I know on github I would made a 0.x
release already ages ago but knowing I won't have time to work on it
anymore I keep pushing this out at commons.


Wouldn't this be a case to allow and use intermediate milestone releases?

Using a 1.0-Mxx version would make still clear to the users things haven't
settled yet (API wise), so should not limit or restrict making API changes
before a final 1.0 release, but would help both the community and the
project moving. More likely to incite further involvement and
contributions, etc.

Being 'stuck' on getting a (final) 1.0 release out because everything
should be settled and 'frozen' (API wise) first doesn't make sense to me
at all.


We should not be so afraid to switch to 2.x if the 1.x API turns out to be
cumbersome in some cases. Typically you may also increase Java level in the
meantime and therefore eventually even have a benefit of new possibilities.


"Release early and often" really is what keeps open source projects moving
forward, *any* policy which blocks that is plain wrong and should be
fixed.

Note: I'm not saying I'm against the strict versioning rules, but those
should NOT block getting to a 1.0 release easily.
And I don't think they do. Isn't this where Milestone releases are meant
for?


I am not a big fan of milestones unless we really have a forced schedule for
the final release. If we get into the situation that the milestone is the
latest release for months, we get into jar hell again, because that
milestone is then *used* like any proper release. You cannot prevent this.

There is a reason why I have to use for a (private) Maven plugin an artifact
like org.codehaus.plexus:plexus-container-default:jar:1.0-alpha-9-stable

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Ate Douma]

Sigh, typical mistake of forgetting to provide the link referenced further 
below:

[1] http://commons.apache.org/releases/versioning.html#Milestone_Releases

On 10/10/2013 01:26 PM, Ate Douma wrote:

I've move this into a separate [DISCUSS] thread as I think it needs separate
discussion.

Jörg gave some objections below about using Milestone releases, as I proposed
earlier to support releasing intermediate versions of a not-yet-stabalized
component.

While I understand his problems with unstable versions potentially getting
'stuck' for long time, where end-users *might* start expecting them to remain
stable, I don't agree this is, or should be, the common case. Or at least not an
argument to hold against using such 0.x or -Milestone releases.

Instead, the whole point is to get project/component development moving *faster*
by allowing *experimental* end-users to provide feedback, and more flexibility
and convenience for the developers of such project/component.

The idea to have to 'switch' to a next major version for any incompatibile
change, as Jörg proposes, requiring package changes, whatnot, while a project
clearly is not ready to stabalize, really puts way too much hurdles up for both
the developers *and* such experimental end-users, as they would HAVE to change
all of their code to be able to provide AND leaverage such new 0.x or Milestone
version.

Case in point: SCXML
If we are allowed to start working on this component shortly, we intend to, and
HAVE to switch to a 1.0 version first, as there already is a 0.9 version release
out, while we will need to move to newer JDK and incompatible API changes
anyway. At the same time, getting a final/stabalized 1.0 release out most
certainly will take several iterations.
I don't want to have to wait doing an intermediate release, nor rapidly having
to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone releases are
acceptable for this purpose.
Of course I inteded to say 'just because Milestone releases are NOT acceptable 
for this purpose'.



Where would Milestone releases [1] be useful for
otherwise, anyway?

I think a real problem might arise IF other components (or 3rd party libraries)
would start depending directly on such Milestone releases, potentially
introducing unexpected instabilities for end-users. And maybe it is worthwhile
to make such usages, at least for Commons, prohibited. That would make sense to 
me.

But for components like SCXML, javaflow, or csv, this I don't think would be a
real issue. Those end-users making use of these experimental components are, or
should be very well aware, of the added responsibility they take depending on a
not-yet-stabilized version, as clearly is also indicated by the version, as well
as SHOULD be prominently documented in the release notes, readme, etc.

Thoughts?

Ate

On 10/10/2013 12:45 PM, Benedikt Ritter wrote:

I like the idea of releasing 0.x versions. A good example is [csv]. I would
have no problem with releasing the current trunk as 0.9. At the moment [csv]
is just another component we don't releaese because we want to come up with a
perfect API (and I take responsibility for that :-)

Benedikt

Send from my mobile device


Am 10.10.2013 um 12:15 schrieb Jörg Schaible :

Hi,

Ate Douma wrote:


On 10/10/2013 12:24 AM, Torsten Curdt wrote:
Every now and then I keep getting requests via private mail asking to
release javaflow as it seems to be working for people. Yet I know there
is still so much essential stuff to fix for a 1.0 release.

Crossing over to the other thread: I know on github I would made a 0.x
release already ages ago but knowing I won't have time to work on it
anymore I keep pushing this out at commons.


Wouldn't this be a case to allow and use intermediate milestone releases?

Using a 1.0-Mxx version would make still clear to the users things haven't
settled yet (API wise), so should not limit or restrict making API changes
before a final 1.0 release, but would help both the community and the
project moving. More likely to incite further involvement and
contributions, etc.

Being 'stuck' on getting a (final) 1.0 release out because everything
should be settled and 'frozen' (API wise) first doesn't make sense to me
at all.


We should not be so afraid to switch to 2.x if the 1.x API turns out to be
cumbersome in some cases. Typically you may also increase Java level in the
meantime and therefore eventually even have a benefit of new possibilities.


"Release early and often" really is what keeps open source projects moving
forward, *any* policy which blocks that is plain wrong and should be
fixed.

Note: I'm not saying I'm against the strict versioning rules, but those
should NOT block getting to a 1.0 release easily.
And I don't think they do. Isn't this where Milestone releases are meant
for?


I am not a big fan of milestones unless we really have a forced schedule for
the final release. If we get into the situation that the milestone is the
latest release for months,

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

[James Carman]

I'm okay with alpha/milestone/rc/whatever.  Do we promote them to central
or leave them local?  Keeping them in-house might help keep folks from
incorporating them into production code.  However I'm okay with publishing
too.  Hibernate has done this for years (rc's).

On Thursday, October 10, 2013, Ate Douma wrote:

> I've move this into a separate [DISCUSS] thread as I think it needs
> separate discussion.
>
> Jörg gave some objections below about using Milestone releases, as I
> proposed earlier to support releasing intermediate versions of a
> not-yet-stabalized component.
>
> While I understand his problems with unstable versions potentially getting
> 'stuck' for long time, where end-users *might* start expecting them to
> remain stable, I don't agree this is, or should be, the common case. Or at
> least not an argument to hold against using such 0.x or -Milestone releases.
>
> Instead, the whole point is to get project/component development moving
> *faster* by allowing *experimental* end-users to provide feedback, and more
> flexibility and convenience for the developers of such project/component.
>
> The idea to have to 'switch' to a next major version for any incompatibile
> change, as Jörg proposes, requiring package changes, whatnot, while a
> project clearly is not ready to stabalize, really puts way too much hurdles
> up for both the developers *and* such experimental end-users, as they would
> HAVE to change all of their code to be able to provide AND leaverage such
> new 0.x or Milestone version.
>
> Case in point: SCXML
> If we are allowed to start working on this component shortly, we intend
> to, and HAVE to switch to a 1.0 version first, as there already is a 0.9
> version release out, while we will need to move to newer JDK and
> incompatible API changes anyway. At the same time, getting a
> final/stabalized 1.0 release out most certainly will take several
> iterations.
> I don't want to have to wait doing an intermediate release, nor rapidly
> having to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone
> releases are acceptable for this purpose. Where would Milestone releases
> [1] be useful for otherwise, anyway?
>
> I think a real problem might arise IF other components (or 3rd party
> libraries) would start depending directly on such Milestone releases,
> potentially introducing unexpected instabilities for end-users. And maybe
> it is worthwhile to make such usages, at least for Commons, prohibited.
> That would make sense to me.
>
> But for components like SCXML, javaflow, or csv, this I don't think would
> be a real issue. Those end-users making use of these experimental
> components are, or should be very well aware, of the added responsibility
> they take depending on a not-yet-stabilized version, as clearly is also
> indicated by the version, as well as SHOULD be prominently documented in
> the release notes, readme, etc.
>
> Thoughts?
>
> Ate
>
> On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
>
>> I like the idea of releasing 0.x versions. A good example is [csv]. I
>> would have no problem with releasing the current trunk as 0.9. At the
>> moment [csv] is just another component we don't releaese because we want to
>> come up with a perfect API (and I take responsibility for that :-)
>>
>> Benedikt
>>
>> Send from my mobile device
>>
>>  Am 10.10.2013 um 12:15 schrieb Jörg Schaible <
>>> joerg.schai...@scalaris.com>:
>>>
>>> Hi,
>>>
>>> Ate Douma wrote:
>>>
>>>  On 10/10/2013 12:24 AM, Torsten Curdt wrote:
> Every now and then I keep getting requests via private mail asking to
> release javaflow as it seems to be working for people. Yet I know there
> is still so much essential stuff to fix for a 1.0 release.
>
> Crossing over to the other thread: I know on github I would made a 0.x
> release already ages ago but knowing I won't have time to work on it
> anymore I keep pushing this out at commons.
>

 Wouldn't this be a case to allow and use intermediate milestone
 releases?

 Using a 1.0-Mxx version would make still clear to the users things
 haven't
 settled yet (API wise), so should not limit or restrict making API
 changes
 before a final 1.0 release, but would help both the community and the
 project moving. More likely to incite further involvement and
 contributions, etc.

 Being 'stuck' on getting a (final) 1.0 release out because everything
 should be settled and 'frozen' (API wise) first doesn't make sense to me
 at all.

>>>
>>> We should not be so afraid to switch to 2.x if the 1.x API turns out to
>>> be
>>> cumbersome in some cases. Typically you may also increase Java level in
>>> the
>>> meantime and therefore eventually even have a benefit of new
>>> possibilities.
>>>
>>>  "Release early and often" really is what keeps open source projects
 moving
 forward, *any* policy which blocks that is plain wrong and should be
 fixed.

 Note: I

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[James Carman]

Rookie ;).  You had me at "faster"! :)

On Thursday, October 10, 2013, Ate Douma wrote:

> Sigh, typical mistake of forgetting to provide the link referenced further
> below:
>
> [1] http://commons.apache.org/**releases/versioning.html#**
> Milestone_Releases
>
> On 10/10/2013 01:26 PM, Ate Douma wrote:
>
>> I've move this into a separate [DISCUSS] thread as I think it needs
>> separate
>> discussion.
>>
>> Jörg gave some objections below about using Milestone releases, as I
>> proposed
>> earlier to support releasing intermediate versions of a not-yet-stabalized
>> component.
>>
>> While I understand his problems with unstable versions potentially getting
>> 'stuck' for long time, where end-users *might* start expecting them to
>> remain
>> stable, I don't agree this is, or should be, the common case. Or at least
>> not an
>> argument to hold against using such 0.x or -Milestone releases.
>>
>> Instead, the whole point is to get project/component development moving
>> *faster*
>> by allowing *experimental* end-users to provide feedback, and more
>> flexibility
>> and convenience for the developers of such project/component.
>>
>> The idea to have to 'switch' to a next major version for any incompatibile
>> change, as Jörg proposes, requiring package changes, whatnot, while a
>> project
>> clearly is not ready to stabalize, really puts way too much hurdles up
>> for both
>> the developers *and* such experimental end-users, as they would HAVE to
>> change
>> all of their code to be able to provide AND leaverage such new 0.x or
>> Milestone
>> version.
>>
>> Case in point: SCXML
>> If we are allowed to start working on this component shortly, we intend
>> to, and
>> HAVE to switch to a 1.0 version first, as there already is a 0.9 version
>> release
>> out, while we will need to move to newer JDK and incompatible API changes
>> anyway. At the same time, getting a final/stabalized 1.0 release out most
>> certainly will take several iterations.
>> I don't want to have to wait doing an intermediate release, nor rapidly
>> having
>> to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone releases
>> are
>> acceptable for this purpose.
>>
> Of course I inteded to say 'just because Milestone releases are NOT
> acceptable for this purpose'.
>
>  Where would Milestone releases [1] be useful for
>> otherwise, anyway?
>>
>> I think a real problem might arise IF other components (or 3rd party
>> libraries)
>> would start depending directly on such Milestone releases, potentially
>> introducing unexpected instabilities for end-users. And maybe it is
>> worthwhile
>> to make such usages, at least for Commons, prohibited. That would make
>> sense to me.
>>
>> But for components like SCXML, javaflow, or csv, this I don't think would
>> be a
>> real issue. Those end-users making use of these experimental components
>> are, or
>> should be very well aware, of the added responsibility they take
>> depending on a
>> not-yet-stabilized version, as clearly is also indicated by the version,
>> as well
>> as SHOULD be prominently documented in the release notes, readme, etc.
>>
>> Thoughts?
>>
>> Ate
>>
>> On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
>>
>>> I like the idea of releasing 0.x versions. A good example is [csv]. I
>>> would
>>> have no problem with releasing the current trunk as 0.9. At the moment
>>> [csv]
>>> is just another component we don't releaese because we want to come up
>>> with a
>>> perfect API (and I take responsibility for that :-)
>>>
>>> Benedikt
>>>
>>> Send from my mobile device
>>>
>>>  Am 10.10.2013 um 12:15 schrieb Jörg Schaible <
 joerg.schai...@scalaris.com>:

 Hi,

 Ate Douma wrote:

  On 10/10/2013 12:24 AM, Torsten Curdt wrote:
>> Every now and then I keep getting requests via private mail asking to
>> release javaflow as it seems to be working for people. Yet I know
>> there
>> is still so much essential stuff to fix for a 1.0 release.
>>
>> Crossing over to the other thread: I know on github I would made a 0.x
>> release already ages ago but knowing I won't have time to work on it
>> anymore I keep pushing this out at commons.
>>
>
> Wouldn't this be a case to allow and use intermediate milestone
> releases?
>
> Using a 1.0-Mxx version would make still clear to the users things
> haven't
> settled yet (API wise), so should not limit or restrict making API
> changes
> before a final 1.0 release, but would help both the community and the
> project moving. More likely to incite further involvement and
> contributions, etc.
>
> Being 'stuck' on getting a (final) 1.0 release out because everything
> should be settled and 'frozen' (API wise) first doesn't make sense to
> me
> at all.
>

 We should not be so afraid to switch to 2.x if the 1.x API turns out to
 be
 cumberso

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Emmanuel Bourg]

Le 10/10/2013 13:26, Ate Douma a écrit :

> Thoughts?

A solution could be to change the package for every preview release.
Something like:

   org.apache.commons.experimental.

So, for CSV we could release a 0.8 and 0.9 version under the packages:

   org.apache.commons.experimental.csv8
   org.apache.commons.experimental.csv9

The package translation could probably be automated by the shade plugin,
such that we keep developing with the org.apache.commons.csv package.

Emmanuel Bourg


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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Ate Douma]

On 10/10/2013 01:36 PM, Emmanuel Bourg wrote:

Le 10/10/2013 13:26, Ate Douma a écrit :


Thoughts?


A solution could be to change the package for every preview release.
Something like:

org.apache.commons.experimental.

So, for CSV we could release a 0.8 and 0.9 version under the packages:

org.apache.commons.experimental.csv8
org.apache.commons.experimental.csv9

The package translation could probably be automated by the shade plugin,
such that we keep developing with the org.apache.commons.csv package.


While doing this might be somewhat automated, sure, I still would not favor 
this.
I think it tries to solve more of a perceived than an actual problem.
And it is not convenient for the experimental end-users either, because they 
most definitely will HAVE to modify their code (manually).




Emmanuel Bourg


-
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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[James Carman]

Agreed.  Keep it simple.

On Thursday, October 10, 2013, Ate Douma wrote:

> On 10/10/2013 01:36 PM, Emmanuel Bourg wrote:
>
>> Le 10/10/2013 13:26, Ate Douma a écrit :
>>
>>  Thoughts?
>>>
>>
>> A solution could be to change the package for every preview release.
>> Something like:
>>
>> org.apache.commons.**experimental.<**number>
>>
>> So, for CSV we could release a 0.8 and 0.9 version under the packages:
>>
>> org.apache.commons.**experimental.csv8
>> org.apache.commons.**experimental.csv9
>>
>> The package translation could probably be automated by the shade plugin,
>> such that we keep developing with the org.apache.commons.csv package.
>>
>
> While doing this might be somewhat automated, sure, I still would not
> favor this.
> I think it tries to solve more of a perceived than an actual problem.
> And it is not convenient for the experimental end-users either, because
> they most definitely will HAVE to modify their code (manually).
>
>
>> Emmanuel Bourg
>>
>>
>> --**--**-
>> 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
>
>

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Emmanuel Bourg]

Le 10/10/2013 13:47, Ate Douma a écrit :

> While doing this might be somewhat automated, sure, I still would not
> favor this.
> I think it tries to solve more of a perceived than an actual problem.

I'm afraid this is more than a perceived issue, the plexus-container
example given by Jörg is a very good one. Pushing drastically
incompatible versions to Maven Central is not a good service for the users.

I think my suggestion is a good compromise, otherwise the die-hard
compatibility defenders here will never agree to publish incompatible
artifacts to Maven Central.


> And it is not convenient for the experimental end-users either, because
> they most definitely will HAVE to modify their code (manually).

I agree this is annoying, but this has to be balanced with the annoyance
of dealing with incompatible dependencies (for example, components
depending on different versions of BouncyCastle). It's easy to rename an
import in your code compared to fixing a jar hell situation.

Emmanuel Bourg


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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Jörg Schaible]

Hi Ate,

Ate Douma wrote:

> On 10/10/2013 01:36 PM, Emmanuel Bourg wrote:
>> Le 10/10/2013 13:26, Ate Douma a écrit :
>>
>>> Thoughts?
>>
>> A solution could be to change the package for every preview release.
>> Something like:
>>
>> org.apache.commons.experimental.
>>
>> So, for CSV we could release a 0.8 and 0.9 version under the packages:
>>
>> org.apache.commons.experimental.csv8
>> org.apache.commons.experimental.csv9
>>
>> The package translation could probably be automated by the shade plugin,
>> such that we keep developing with the org.apache.commons.csv package.
> 
> While doing this might be somewhat automated, sure, I still would not
> favor this. I think it tries to solve more of a perceived than an actual
> problem. And it is not convenient for the experimental end-users either,
> because they most definitely will HAVE to modify their code (manually).

I am not strictly against milestones, but it requires a strict time frame 
for a final release. And I fear with all my experience gained in the years 
as Commons committer, that we will fail here badly. I was myself too often 
suddenly occupied with real life tasks.

The problem in Commons is that our components are often widely used and the 
probability to depend transitively on different versions of the same Commons 
component is very high just by using a view different components of 3rd 
parties.

The problem now with long lasting milestones is that for a final release the 
API might break again and suddenly you can no longer use safely those 3rd 
party components together anymore, just because one of it depends 
(transitively) on the milestone while all other can rely on the stable API.

IMHO Emmanuel made an interesting suggestion, but I would not take it so 
far. Why not have a special package for any kind of alpha/beta/milestone 
release? For CSV we would then simply have:

  org.apache.commons.experimental.csv

Advantage: Early adopters might already test the API without the requirement 
to 'update' the imports with every new milestone, but they are prepared to 
make API adjustments anyway and they are immediately remembered that they 
should not depend on the stuff in a release.

Even if some stupid vendor uses now the experimental package for its own 
release, it is a lot easier afterwards to shade this package automatically 
for my own product without breaking any other stuff using the final API.

Cheers,
Jörg



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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

[Gary Gregory]

I think "milestone" releases works if you have a clear development
plan and schedule. I've never seen it be the case in Commons. Calling
"releases" to Maven and dist, Alphas and Betas make more sense for us
IMO.

Gary

On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma  wrote:
> I've move this into a separate [DISCUSS] thread as I think it needs separate
> discussion.
>
> Jörg gave some objections below about using Milestone releases, as I
> proposed earlier to support releasing intermediate versions of a
> not-yet-stabalized component.
>
> While I understand his problems with unstable versions potentially getting
> 'stuck' for long time, where end-users *might* start expecting them to
> remain stable, I don't agree this is, or should be, the common case. Or at
> least not an argument to hold against using such 0.x or -Milestone releases.
>
> Instead, the whole point is to get project/component development moving
> *faster* by allowing *experimental* end-users to provide feedback, and more
> flexibility and convenience for the developers of such project/component.
>
> The idea to have to 'switch' to a next major version for any incompatibile
> change, as Jörg proposes, requiring package changes, whatnot, while a
> project clearly is not ready to stabalize, really puts way too much hurdles
> up for both the developers *and* such experimental end-users, as they would
> HAVE to change all of their code to be able to provide AND leaverage such
> new 0.x or Milestone version.
>
> Case in point: SCXML
> If we are allowed to start working on this component shortly, we intend to,
> and HAVE to switch to a 1.0 version first, as there already is a 0.9 version
> release out, while we will need to move to newer JDK and incompatible API
> changes anyway. At the same time, getting a final/stabalized 1.0 release out
> most certainly will take several iterations.
> I don't want to have to wait doing an intermediate release, nor rapidly
> having to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone
> releases are acceptable for this purpose. Where would Milestone releases [1]
> be useful for otherwise, anyway?
>
> I think a real problem might arise IF other components (or 3rd party
> libraries) would start depending directly on such Milestone releases,
> potentially introducing unexpected instabilities for end-users. And maybe it
> is worthwhile to make such usages, at least for Commons, prohibited. That
> would make sense to me.
>
> But for components like SCXML, javaflow, or csv, this I don't think would be
> a real issue. Those end-users making use of these experimental components
> are, or should be very well aware, of the added responsibility they take
> depending on a not-yet-stabilized version, as clearly is also indicated by
> the version, as well as SHOULD be prominently documented in the release
> notes, readme, etc.
>
> Thoughts?
>
> Ate
>
> On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
>>
>> I like the idea of releasing 0.x versions. A good example is [csv]. I
>> would have no problem with releasing the current trunk as 0.9. At the moment
>> [csv] is just another component we don't releaese because we want to come up
>> with a perfect API (and I take responsibility for that :-)
>>
>> Benedikt
>>
>> Send from my mobile device
>>
>>> Am 10.10.2013 um 12:15 schrieb Jörg Schaible
>>> :
>>>
>>> Hi,
>>>
>>> Ate Douma wrote:
>>>
> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
> Every now and then I keep getting requests via private mail asking to
> release javaflow as it seems to be working for people. Yet I know there
> is still so much essential stuff to fix for a 1.0 release.
>
> Crossing over to the other thread: I know on github I would made a 0.x
> release already ages ago but knowing I won't have time to work on it
> anymore I keep pushing this out at commons.


 Wouldn't this be a case to allow and use intermediate milestone
 releases?

 Using a 1.0-Mxx version would make still clear to the users things
 haven't
 settled yet (API wise), so should not limit or restrict making API
 changes
 before a final 1.0 release, but would help both the community and the
 project moving. More likely to incite further involvement and
 contributions, etc.

 Being 'stuck' on getting a (final) 1.0 release out because everything
 should be settled and 'frozen' (API wise) first doesn't make sense to me
 at all.
>>>
>>>
>>> We should not be so afraid to switch to 2.x if the 1.x API turns out to
>>> be
>>> cumbersome in some cases. Typically you may also increase Java level in
>>> the
>>> meantime and therefore eventually even have a benefit of new
>>> possibilities.
>>>
 "Release early and often" really is what keeps open source projects
 moving
 forward, *any* policy which blocks that is plain wrong and should be
 fixed.

 Note: I'm not saying I'm against the strict versioning rules, but those
 should NOT

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Gary Gregory]

On Thu, Oct 10, 2013 at 7:36 AM, Emmanuel Bourg  wrote:
> Le 10/10/2013 13:26, Ate Douma a écrit :
>
>> Thoughts?
>
> A solution could be to change the package for every preview release.
> Something like:
>
>org.apache.commons.experimental.
>
> So, for CSV we could release a 0.8 and 0.9 version under the packages:
>
>org.apache.commons.experimental.csv8
>org.apache.commons.experimental.csv9
>
> The package translation could probably be automated by the shade plugin,
> such that we keep developing with the org.apache.commons.csv package.
>
> Emmanuel Bourg

I call this "Extreme Versioning", and I've thought about it in the
past. Each release lives in it's own package, major, minor,
maintenance. As a developer, this leads you to make a conscious choice
as to when to pick up a bug fix or new feature from a new version of a
jar, you have to act. This is different than just new dropping jars
into your classpath (or POM) and hoping for the best. It also
guarantees binary compatibility, BC becomes a non-issue. It is an
extreme POV to be sure. If I want to create an "unsupported" jar
combo, I have to shade jars and change package names.

Gary

>
>
> -
> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Benedikt Ritter]

Send from my mobile device

> Am 10.10.2013 um 14:44 schrieb Gary Gregory :
> 
>> On Thu, Oct 10, 2013 at 7:36 AM, Emmanuel Bourg  wrote:
>> Le 10/10/2013 13:26, Ate Douma a écrit :
>> 
>>> Thoughts?
>> 
>> A solution could be to change the package for every preview release.
>> Something like:
>> 
>>   org.apache.commons.experimental.
>> 
>> So, for CSV we could release a 0.8 and 0.9 version under the packages:
>> 
>>   org.apache.commons.experimental.csv8
>>   org.apache.commons.experimental.csv9
>> 
>> The package translation could probably be automated by the shade plugin,
>> such that we keep developing with the org.apache.commons.csv package.
>> 
>> Emmanuel Bourg
> 
> I call this "Extreme Versioning", and I've thought about it in the
> past. Each release lives in it's own package, major, minor,
> maintenance. As a developer, this leads you to make a conscious choice
> as to when to pick up a bug fix or new feature from a new version of a
> jar, you have to act. This is different than just new dropping jars
> into your classpath (or POM) and hoping for the best. It also
> guarantees binary compatibility, BC becomes a non-issue. It is an
> extreme POV to be sure. If I want to create an "unsupported" jar
> combo, I have to shade jars and change package names.

I feel we've nearly arrived in OSGi land ;-)

> 
> Gary
> 
>> 
>> 
>> -
>> 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
> JUnit in Action, Second Edition
> Spring Batch in Action
> 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
> 

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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

[James Carman]

On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory  wrote:
> I think "milestone" releases works if you have a clear development
> plan and schedule. I've never seen it be the case in Commons. Calling
> "releases" to Maven and dist, Alphas and Betas make more sense for us
> IMO.
>

I don't care what we call it.  They key is that we set up the
expectation with our users.  If you use this release, do NOT use it in
production code.  It is not "supported", meaning we aren't going to
fix bugs in that alpha version if we have already released its
subsequent full release version (or a subsequent alpha).

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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[James Carman]

On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg  wrote:
>
> I'm afraid this is more than a perceived issue, the plexus-container
> example given by Jörg is a very good one. Pushing drastically
> incompatible versions to Maven Central is not a good service for the users.
>
> I think my suggestion is a good compromise, otherwise the die-hard
> compatibility defenders here will never agree to publish incompatible
> artifacts to Maven Central.
>

This gets back to my earlier comments on another thread.  We can't try
to stupid-proof our code.  If our users want to do something stupid,
we can't protect them from themselves.  If they want to "release" code
which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
them.

>
> I agree this is annoying, but this has to be balanced with the annoyance
> of dealing with incompatible dependencies (for example, components
> depending on different versions of BouncyCastle). It's easy to rename an
> import in your code compared to fixing a jar hell situation.
>

If a third-party library releases a version which points at one of our
alpha releases and relies upon an API that they've been told may not
be stable, then they need to fix it.  Again, we can boil the ocean
trying to think up all the stupid things people can do with our
software and try to code/process around it, but at the end of the day,
you can't fix stupid.

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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Ate Douma]

On 10/10/2013 03:06 PM, James Carman wrote:

On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg  wrote:


I'm afraid this is more than a perceived issue, the plexus-container
example given by Jörg is a very good one. Pushing drastically
incompatible versions to Maven Central is not a good service for the users.

I think my suggestion is a good compromise, otherwise the die-hard
compatibility defenders here will never agree to publish incompatible
artifacts to Maven Central.



This gets back to my earlier comments on another thread.  We can't try
to stupid-proof our code.  If our users want to do something stupid,
we can't protect them from themselves.  If they want to "release" code
which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
them.



I agree this is annoying, but this has to be balanced with the annoyance
of dealing with incompatible dependencies (for example, components
depending on different versions of BouncyCastle). It's easy to rename an
import in your code compared to fixing a jar hell situation.



If a third-party library releases a version which points at one of our
alpha releases and relies upon an API that they've been told may not
be stable, then they need to fix it.  Again, we can boil the ocean
trying to think up all the stupid things people can do with our
software and try to code/process around it, but at the end of the day,
you can't fix stupid.


Amen to that



-
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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

[Ate Douma]

On 10/10/2013 03:00 PM, James Carman wrote:

On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory  wrote:

I think "milestone" releases works if you have a clear development
plan and schedule. I've never seen it be the case in Commons. Calling
"releases" to Maven and dist, Alphas and Betas make more sense for us
IMO.



I don't care what we call it.  They key is that we set up the
expectation with our users.  If you use this release, do NOT use it in
production code.  It is not "supported", meaning we aren't going to
fix bugs in that alpha version if we have already released its
subsequent full release version (or a subsequent alpha).


Indeed and agreed.

I also don't care if its called milestone or alpha or whatever.
But we already have explicit wording for milestone releases [1], also clearly 
stating such releases are not supported.


So I'm actually only asking *confirmation* to use already established rules.

[1] http://commons.apache.org/releases/versioning.html#Milestone_Releases



-
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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

[James Carman]

We definitely need to make sure our naming scheme will work with maven
properly.  Hopefully commons-foo:1.0 would supercede
commons-foo:1.0-M1.  Again, I really don't care what we call it, as
long as we manage expectations and don't dork up maven.

On Thu, Oct 10, 2013 at 9:25 AM, Ate Douma  wrote:
> On 10/10/2013 03:00 PM, James Carman wrote:
>>
>> On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory 
>> wrote:
>>>
>>> I think "milestone" releases works if you have a clear development
>>> plan and schedule. I've never seen it be the case in Commons. Calling
>>> "releases" to Maven and dist, Alphas and Betas make more sense for us
>>> IMO.
>>>
>>
>> I don't care what we call it.  They key is that we set up the
>> expectation with our users.  If you use this release, do NOT use it in
>> production code.  It is not "supported", meaning we aren't going to
>> fix bugs in that alpha version if we have already released its
>> subsequent full release version (or a subsequent alpha).
>
>
> Indeed and agreed.
>
> I also don't care if its called milestone or alpha or whatever.
> But we already have explicit wording for milestone releases [1], also
> clearly stating such releases are not supported.
>
> So I'm actually only asking *confirmation* to use already established rules.
>
> [1] http://commons.apache.org/releases/versioning.html#Milestone_Releases
>
>
>>
>> -
>> 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
>

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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Gary Gregory]

On Thu, Oct 10, 2013 at 9:06 AM, James Carman
 wrote:
> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg  wrote:
>>
>> I'm afraid this is more than a perceived issue, the plexus-container
>> example given by Jörg is a very good one. Pushing drastically
>> incompatible versions to Maven Central is not a good service for the users.
>>
>> I think my suggestion is a good compromise, otherwise the die-hard
>> compatibility defenders here will never agree to publish incompatible
>> artifacts to Maven Central.
>>
>
> This gets back to my earlier comments on another thread.  We can't try
> to stupid-proof our code.  If our users want to do something stupid,
> we can't protect them from themselves.  If they want to "release" code
> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
> them.
>
>>
>> I agree this is annoying, but this has to be balanced with the annoyance
>> of dealing with incompatible dependencies (for example, components
>> depending on different versions of BouncyCastle). It's easy to rename an
>> import in your code compared to fixing a jar hell situation.
>>
>
> If a third-party library releases a version which points at one of our
> alpha releases and relies upon an API that they've been told may not
> be stable, then they need to fix it.  Again, we can boil the ocean
> trying to think up all the stupid things people can do with our
> software and try to code/process around it, but at the end of the day,
> you can't fix stupid.

Indeed, developers and users will forever find creative and painful
ways to shoot themselves in the foot and other appendages.

Conversely, we should not hand out defective weaponry by breaking
Binary Compatibility (this relates to a discussion on another thread:
I claim it is never OK to break BC, you release a new (Java) package
to do the equivalent).

Gary

>
> -
> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

[Gary Gregory]

On Thu, Oct 10, 2013 at 9:00 AM, James Carman
 wrote:
> On Thu, Oct 10, 2013 at 8:35 AM, Gary Gregory  wrote:
>> I think "milestone" releases works if you have a clear development
>> plan and schedule. I've never seen it be the case in Commons. Calling
>> "releases" to Maven and dist, Alphas and Betas make more sense for us
>> IMO.
>>
>
> I don't care what we call it.  They key is that we set up the
> expectation with our users.  If you use this release, do NOT use it in
> production code.  It is not "supported", meaning we aren't going to
> fix bugs in that alpha version if we have already released its
> subsequent full release version (or a subsequent alpha).

Of course, but naming is important, it communicates intent. With alpha
and beta, you can describe two kinds of releases, with milestone, only
one.

Gary

>
> -
> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Ate Douma]

On 10/10/2013 03:47 PM, Gary Gregory wrote:

On Thu, Oct 10, 2013 at 9:06 AM, James Carman
 wrote:

On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg  wrote:


I'm afraid this is more than a perceived issue, the plexus-container
example given by Jörg is a very good one. Pushing drastically
incompatible versions to Maven Central is not a good service for the users.

I think my suggestion is a good compromise, otherwise the die-hard
compatibility defenders here will never agree to publish incompatible
artifacts to Maven Central.



This gets back to my earlier comments on another thread.  We can't try
to stupid-proof our code.  If our users want to do something stupid,
we can't protect them from themselves.  If they want to "release" code
which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
them.



I agree this is annoying, but this has to be balanced with the annoyance
of dealing with incompatible dependencies (for example, components
depending on different versions of BouncyCastle). It's easy to rename an
import in your code compared to fixing a jar hell situation.



If a third-party library releases a version which points at one of our
alpha releases and relies upon an API that they've been told may not
be stable, then they need to fix it.  Again, we can boil the ocean
trying to think up all the stupid things people can do with our
software and try to code/process around it, but at the end of the day,
you can't fix stupid.


Indeed, developers and users will forever find creative and painful
ways to shoot themselves in the foot and other appendages.

Conversely, we should not hand out defective weaponry by breaking
Binary Compatibility (this relates to a discussion on another thread:
I claim it is never OK to break BC, you release a new (Java) package
to do the equivalent).


I state that an alpha release (which I gather you prefer above calling it 
milestones), by definition, cannot have a 'Compatibility' claim to begin with, 
hence cannot break one either.


So, are you OK with alpha releases, which do NOT claim any stability nor 
compatibility?




Gary



-
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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[James Carman]

I think the idea is that we don't break BC between an older full
version and a new alpha/milestone/rc/whatever, unless of course, the
new alpha/milestone/rc/whatever release is on a new major version.
For example, we can have API breaks between commons-foo-1.0 and
commons-foo-2.0-alpha.  We can have API breaks between
commons-foo-2.0-alpha1 and commons-foo-2.0-alpha2.  We cannot have API
breaks between commons-foo-2.0 and commons-foo-2.1-alpha.  How does
that sound (the concept not the choice of alpha)?

On Thu, Oct 10, 2013 at 9:47 AM, Gary Gregory  wrote:
> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
>  wrote:
>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg  wrote:
>>>
>>> I'm afraid this is more than a perceived issue, the plexus-container
>>> example given by Jörg is a very good one. Pushing drastically
>>> incompatible versions to Maven Central is not a good service for the users.
>>>
>>> I think my suggestion is a good compromise, otherwise the die-hard
>>> compatibility defenders here will never agree to publish incompatible
>>> artifacts to Maven Central.
>>>
>>
>> This gets back to my earlier comments on another thread.  We can't try
>> to stupid-proof our code.  If our users want to do something stupid,
>> we can't protect them from themselves.  If they want to "release" code
>> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
>> them.
>>
>>>
>>> I agree this is annoying, but this has to be balanced with the annoyance
>>> of dealing with incompatible dependencies (for example, components
>>> depending on different versions of BouncyCastle). It's easy to rename an
>>> import in your code compared to fixing a jar hell situation.
>>>
>>
>> If a third-party library releases a version which points at one of our
>> alpha releases and relies upon an API that they've been told may not
>> be stable, then they need to fix it.  Again, we can boil the ocean
>> trying to think up all the stupid things people can do with our
>> software and try to code/process around it, but at the end of the day,
>> you can't fix stupid.
>
> Indeed, developers and users will forever find creative and painful
> ways to shoot themselves in the foot and other appendages.
>
> Conversely, we should not hand out defective weaponry by breaking
> Binary Compatibility (this relates to a discussion on another thread:
> I claim it is never OK to break BC, you release a new (Java) package
> to do the equivalent).
>
> Gary
>
>>
>> -
>> 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
> JUnit in Action, Second Edition
> Spring Batch in Action
> 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
>

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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Gary Gregory]

On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma  wrote:
> On 10/10/2013 03:47 PM, Gary Gregory wrote:
>>
>> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
>>  wrote:
>>>
>>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg 
>>> wrote:


 I'm afraid this is more than a perceived issue, the plexus-container
 example given by Jörg is a very good one. Pushing drastically
 incompatible versions to Maven Central is not a good service for the
 users.

 I think my suggestion is a good compromise, otherwise the die-hard
 compatibility defenders here will never agree to publish incompatible
 artifacts to Maven Central.

>>>
>>> This gets back to my earlier comments on another thread.  We can't try
>>> to stupid-proof our code.  If our users want to do something stupid,
>>> we can't protect them from themselves.  If they want to "release" code
>>> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
>>> them.
>>>

 I agree this is annoying, but this has to be balanced with the annoyance
 of dealing with incompatible dependencies (for example, components
 depending on different versions of BouncyCastle). It's easy to rename an
 import in your code compared to fixing a jar hell situation.

>>>
>>> If a third-party library releases a version which points at one of our
>>> alpha releases and relies upon an API that they've been told may not
>>> be stable, then they need to fix it.  Again, we can boil the ocean
>>> trying to think up all the stupid things people can do with our
>>> software and try to code/process around it, but at the end of the day,
>>> you can't fix stupid.
>>
>>
>> Indeed, developers and users will forever find creative and painful
>> ways to shoot themselves in the foot and other appendages.
>>
>> Conversely, we should not hand out defective weaponry by breaking
>> Binary Compatibility (this relates to a discussion on another thread:
>> I claim it is never OK to break BC, you release a new (Java) package
>> to do the equivalent).
>
>
> I state that an alpha release (which I gather you prefer above calling it
> milestones), by definition, cannot have a 'Compatibility' claim to begin
> with, hence cannot break one either.
>
> So, are you OK with alpha releases, which do NOT claim any stability nor
> compatibility?

Yes, an alpha is an anything goes release.

Whether or not it is in a special package is a different story :)

Gary

>
>
>>
>> Gary
>>
>>>
>>> -
>>> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[James Carman]

Well, alphas still shouldn't break backward compatibility with a prior
*full* release within a major version number.  If they do, then it's a
bug we need to address it.  So, it's not really "anything goes."  At
least, that's how I'd think about it.  Any new APIs are considered
"volatile" and subject to change before the next full release.

On Thu, Oct 10, 2013 at 10:06 AM, Gary Gregory  wrote:
> On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma  wrote:
>> On 10/10/2013 03:47 PM, Gary Gregory wrote:
>>>
>>> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
>>>  wrote:

 On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg 
 wrote:
>
>
> I'm afraid this is more than a perceived issue, the plexus-container
> example given by Jörg is a very good one. Pushing drastically
> incompatible versions to Maven Central is not a good service for the
> users.
>
> I think my suggestion is a good compromise, otherwise the die-hard
> compatibility defenders here will never agree to publish incompatible
> artifacts to Maven Central.
>

 This gets back to my earlier comments on another thread.  We can't try
 to stupid-proof our code.  If our users want to do something stupid,
 we can't protect them from themselves.  If they want to "release" code
 which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
 them.

>
> I agree this is annoying, but this has to be balanced with the annoyance
> of dealing with incompatible dependencies (for example, components
> depending on different versions of BouncyCastle). It's easy to rename an
> import in your code compared to fixing a jar hell situation.
>

 If a third-party library releases a version which points at one of our
 alpha releases and relies upon an API that they've been told may not
 be stable, then they need to fix it.  Again, we can boil the ocean
 trying to think up all the stupid things people can do with our
 software and try to code/process around it, but at the end of the day,
 you can't fix stupid.
>>>
>>>
>>> Indeed, developers and users will forever find creative and painful
>>> ways to shoot themselves in the foot and other appendages.
>>>
>>> Conversely, we should not hand out defective weaponry by breaking
>>> Binary Compatibility (this relates to a discussion on another thread:
>>> I claim it is never OK to break BC, you release a new (Java) package
>>> to do the equivalent).
>>
>>
>> I state that an alpha release (which I gather you prefer above calling it
>> milestones), by definition, cannot have a 'Compatibility' claim to begin
>> with, hence cannot break one either.
>>
>> So, are you OK with alpha releases, which do NOT claim any stability nor
>> compatibility?
>
> Yes, an alpha is an anything goes release.
>
> Whether or not it is in a special package is a different story :)
>
> Gary
>
>>
>>
>>>
>>> Gary
>>>

 -
 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
> JUnit in Action, Second Edition
> Spring Batch in Action
> 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
>

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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Ate Douma]

On 10/10/2013 04:06 PM, Gary Gregory wrote:

On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma  wrote:

On 10/10/2013 03:47 PM, Gary Gregory wrote:


On Thu, Oct 10, 2013 at 9:06 AM, James Carman
 wrote:


On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg 
wrote:



I'm afraid this is more than a perceived issue, the plexus-container
example given by Jörg is a very good one. Pushing drastically
incompatible versions to Maven Central is not a good service for the
users.

I think my suggestion is a good compromise, otherwise the die-hard
compatibility defenders here will never agree to publish incompatible
artifacts to Maven Central.



This gets back to my earlier comments on another thread.  We can't try
to stupid-proof our code.  If our users want to do something stupid,
we can't protect them from themselves.  If they want to "release" code
which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
them.



I agree this is annoying, but this has to be balanced with the annoyance
of dealing with incompatible dependencies (for example, components
depending on different versions of BouncyCastle). It's easy to rename an
import in your code compared to fixing a jar hell situation.



If a third-party library releases a version which points at one of our
alpha releases and relies upon an API that they've been told may not
be stable, then they need to fix it.  Again, we can boil the ocean
trying to think up all the stupid things people can do with our
software and try to code/process around it, but at the end of the day,
you can't fix stupid.



Indeed, developers and users will forever find creative and painful
ways to shoot themselves in the foot and other appendages.

Conversely, we should not hand out defective weaponry by breaking
Binary Compatibility (this relates to a discussion on another thread:
I claim it is never OK to break BC, you release a new (Java) package
to do the equivalent).



I state that an alpha release (which I gather you prefer above calling it
milestones), by definition, cannot have a 'Compatibility' claim to begin
with, hence cannot break one either.

So, are you OK with alpha releases, which do NOT claim any stability nor
compatibility?


Yes, an alpha is an anything goes release.

Thanks, that's all I needed to hear :)



Whether or not it is in a special package is a different story :)


But because it is an 'anything goes release', it doesn't really matter, is up to 
the developer(s), and at any rate CANNOT be a restriction on a release.


Ate



Gary






Gary



-
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









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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Ate Douma]

On 10/10/2013 04:13 PM, James Carman wrote:

Well, alphas still shouldn't break backward compatibility with a prior
*full* release within a major version number.  If they do, then it's a
bug we need to address it.  So, it's not really "anything goes."  At
least, that's how I'd think about it.  Any new APIs are considered
"volatile" and subject to change before the next full release.


Yes, that is a good refinement. "Anything goes" indeed isn't needed nor asked 
for.

So... as we seem to get to an understanding here with respect to the meaning and 
usage of 'alpha' releases, how about adding this to the Versioning 
documentation? Currently there is wording for milestones, but not yet alpha 
releases.


I'm a bit unfamiliar yet with the 'rules' within Commons concerning such 
changes. I'm willing to create an issue for this and draft up a documentation 
patch for it, but maybe this needs formal voting by the PMC first?


Thanks, Ate



On Thu, Oct 10, 2013 at 10:06 AM, Gary Gregory  wrote:

On Thu, Oct 10, 2013 at 9:55 AM, Ate Douma  wrote:

On 10/10/2013 03:47 PM, Gary Gregory wrote:


On Thu, Oct 10, 2013 at 9:06 AM, James Carman
 wrote:


On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg 
wrote:



I'm afraid this is more than a perceived issue, the plexus-container
example given by Jörg is a very good one. Pushing drastically
incompatible versions to Maven Central is not a good service for the
users.

I think my suggestion is a good compromise, otherwise the die-hard
compatibility defenders here will never agree to publish incompatible
artifacts to Maven Central.



This gets back to my earlier comments on another thread.  We can't try
to stupid-proof our code.  If our users want to do something stupid,
we can't protect them from themselves.  If they want to "release" code
which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
them.



I agree this is annoying, but this has to be balanced with the annoyance
of dealing with incompatible dependencies (for example, components
depending on different versions of BouncyCastle). It's easy to rename an
import in your code compared to fixing a jar hell situation.



If a third-party library releases a version which points at one of our
alpha releases and relies upon an API that they've been told may not
be stable, then they need to fix it.  Again, we can boil the ocean
trying to think up all the stupid things people can do with our
software and try to code/process around it, but at the end of the day,
you can't fix stupid.



Indeed, developers and users will forever find creative and painful
ways to shoot themselves in the foot and other appendages.

Conversely, we should not hand out defective weaponry by breaking
Binary Compatibility (this relates to a discussion on another thread:
I claim it is never OK to break BC, you release a new (Java) package
to do the equivalent).



I state that an alpha release (which I gather you prefer above calling it
milestones), by definition, cannot have a 'Compatibility' claim to begin
with, hence cannot break one either.

So, are you OK with alpha releases, which do NOT claim any stability nor
compatibility?


Yes, an alpha is an anything goes release.

Whether or not it is in a special package is a different story :)

Gary






Gary



-
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
JUnit in Action, Second Edition
Spring Batch in Action
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



-
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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Gary Gregory]

On Thu, Oct 10, 2013 at 10:04 AM, James Carman
 wrote:
> I think the idea is that we don't break BC between an older full
> version and a new alpha/milestone/rc/whatever, unless of course, the
> new alpha/milestone/rc/whatever release is on a new major version.
> For example, we can have API breaks between commons-foo-1.0 and
> commons-foo-2.0-alpha.  We can have API breaks between
> commons-foo-2.0-alpha1 and commons-foo-2.0-alpha2.  We cannot have API
> breaks between commons-foo-2.0 and commons-foo-2.1-alpha.  How does
> that sound (the concept not the choice of alpha)?

Sounds reasonable.

Gary

>
> On Thu, Oct 10, 2013 at 9:47 AM, Gary Gregory  wrote:
>> On Thu, Oct 10, 2013 at 9:06 AM, James Carman
>>  wrote:
>>> On Thu, Oct 10, 2013 at 8:25 AM, Emmanuel Bourg  wrote:

 I'm afraid this is more than a perceived issue, the plexus-container
 example given by Jörg is a very good one. Pushing drastically
 incompatible versions to Maven Central is not a good service for the users.

 I think my suggestion is a good compromise, otherwise the die-hard
 compatibility defenders here will never agree to publish incompatible
 artifacts to Maven Central.

>>>
>>> This gets back to my earlier comments on another thread.  We can't try
>>> to stupid-proof our code.  If our users want to do something stupid,
>>> we can't protect them from themselves.  If they want to "release" code
>>> which points to milestone/alpha/rc/SNAPSHOT/whatever, then that's on
>>> them.
>>>

 I agree this is annoying, but this has to be balanced with the annoyance
 of dealing with incompatible dependencies (for example, components
 depending on different versions of BouncyCastle). It's easy to rename an
 import in your code compared to fixing a jar hell situation.

>>>
>>> If a third-party library releases a version which points at one of our
>>> alpha releases and relies upon an API that they've been told may not
>>> be stable, then they need to fix it.  Again, we can boil the ocean
>>> trying to think up all the stupid things people can do with our
>>> software and try to code/process around it, but at the end of the day,
>>> you can't fix stupid.
>>
>> Indeed, developers and users will forever find creative and painful
>> ways to shoot themselves in the foot and other appendages.
>>
>> Conversely, we should not hand out defective weaponry by breaking
>> Binary Compatibility (this relates to a discussion on another thread:
>> I claim it is never OK to break BC, you release a new (Java) package
>> to do the equivalent).
>>
>> Gary
>>
>>>
>>> -
>>> 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
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> 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
>>
>
> -
> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[James Carman]

On Thu, Oct 10, 2013 at 10:19 AM, Ate Douma  wrote:
>
> I'm a bit unfamiliar yet with the 'rules' within Commons concerning such
> changes. I'm willing to create an issue for this and draft up a
> documentation patch for it, but maybe this needs formal voting by the PMC
> first?
>

I'd suggest a vote.  This way we have documentation that a decision
was made to move in this direction and we don't have to re-hash the
discussion every time someone wants to do an alpha release or break BC
between alpha releases.  We should probably vote before establishing
such "policy" changes.  This doesn't mean components *have* to do
alphas if they don't want, but we're merely establishing that it's an
acceptable practice within Commons to do so and more importantly to
establish the expectations when the situation arises.

Hopefully once we get our release process streamlined we can do these
releases much more frequently and get our cool code in our users'
hands quickly!

Great discussions, folks.  I'm glad to see us thinking like this.

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

Re: [DISCUSS] Moving to Git...

[James Carman]

Well, we've had some lengthy discussions about this.  I think there is
at least enough interest to put it up to a vote.  I'll start the
thread here shortly.  We can continue the discussion on this thread so
it doesn't get fragmented.

On Mon, Oct 7, 2013 at 10:10 PM, James Carman
 wrote:
> All,
>
> If we did want to move to Git, we'd probably have to figure out how
> we'd manage our "workflow" (couldn't think of a better word).  I
> suppose we'd have a separate repo for each component?  What about
> proper vs. sandbox?  How would we accommodate that paradigm?  Has
> anyone else already gone through this thought process?  I must admit,
> my git fu isn't what it should be.
>
> James

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

[VOTE] Moving to Git...

[James Carman]

All,

We have had some great discussions about moving our SCM to Git.  I
think it's time to put it to a vote.  So, here we go:

+1 - yes, move to Git
-1 - no, do not move to Git

The vote will be left open for 72 hours.  Go!

James

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

Re: [VOTE] Moving to Git...

[James Carman]

Here's my +1 (binding)

On Thu, Oct 10, 2013 at 10:41 AM, James Carman
 wrote:
> All,
>
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
>
> +1 - yes, move to Git
> -1 - no, do not move to Git
>
> The vote will be left open for 72 hours.  Go!
>
> James

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

Re: [VOTE] Moving to Git...

[Romain Manni-Bucau]

+1

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/10/10 James Carman 

> All,
>
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
>
> +1 - yes, move to Git
> -1 - no, do not move to Git
>
> The vote will be left open for 72 hours.  Go!
>
> James
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases

[Ate Douma]

On 10/10/2013 04:31 PM, James Carman wrote:

On Thu, Oct 10, 2013 at 10:19 AM, Ate Douma  wrote:


I'm a bit unfamiliar yet with the 'rules' within Commons concerning such
changes. I'm willing to create an issue for this and draft up a
documentation patch for it, but maybe this needs formal voting by the PMC
first?



I'd suggest a vote.  This way we have documentation that a decision
was made to move in this direction and we don't have to re-hash the
discussion every time someone wants to do an alpha release or break BC
between alpha releases.  We should probably vote before establishing
such "policy" changes.  This doesn't mean components *have* to do
alphas if they don't want, but we're merely establishing that it's an
acceptable practice within Commons to do so and more importantly to
establish the expectations when the situation arises.


Great!

If OK, I'm willing to draft up a proposal for such a VOTE, with text ready to be 
incorporated in the Versioning documentation once accepted.


Ate


Hopefully once we get our release process streamlined we can do these
releases much more frequently and get our cool code in our users'
hands quickly!

Great discussions, folks.  I'm glad to see us thinking like this.

-
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

[VOTE] Move Apache Commons to Git for SCM...

[James Carman]

All,

We have had some great discussions about moving our SCM to Git.  I
think it's time to put it to a vote.  So, here we go:

+1 - yes, move to Git
-1 - no, do not move to Git

The vote will be left open for 72 hours.  Go!

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

Re: [VOTE] Moving to Git...

[Gilles]

On Thu, 10 Oct 2013 10:41:11 -0400, James Carman wrote:

All,

We have had some great discussions about moving our SCM to Git.  I
think it's time to put it to a vote.  So, here we go:

+1 - yes, move to Git
-1 - no, do not move to Git


-1

Some people have indicated that this move might not address the problem
it is supposed to. No conclusive answer has been provided.


Regards,
Gilles


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

Re: [VOTE] Moving to Git...

[James Carman]

I'm going to start another thread.  For me, in gmail, this got
combined with the [DISCUSS] thread and I don't want votes to get lost.
 Consider this [VOTE] canceled!  Romain, please vote again in the
other thread.  Sorry, folks.

On Thu, Oct 10, 2013 at 10:41 AM, James Carman
 wrote:
> All,
>
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
>
> +1 - yes, move to Git
> -1 - no, do not move to Git
>
> The vote will be left open for 72 hours.  Go!
>
> James

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

Re: [VOTE] Move Apache Commons to Git for SCM...

[James Carman]

Here's my +1 (binding)

On Thu, Oct 10, 2013 at 10:50 AM, James Carman
 wrote:
> All,
>
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
>
> +1 - yes, move to Git
> -1 - no, do not move to Git
>
> The vote will be left open for 72 hours.  Go!

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

Re: [VOTE] Move Apache Commons to Git for SCM...

[Romain Manni-Bucau]

+1 - yes, move to Git

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/10/10 James Carman 

> Here's my +1 (binding)
>
> On Thu, Oct 10, 2013 at 10:50 AM, James Carman
>  wrote:
> > All,
> >
> > We have had some great discussions about moving our SCM to Git.  I
> > think it's time to put it to a vote.  So, here we go:
> >
> > +1 - yes, move to Git
> > -1 - no, do not move to Git
> >
> > The vote will be left open for 72 hours.  Go!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Moving to Git...

[Romain Manni-Bucau]

@Gilles: that's right (and I'm part of people thinking this is not the main
issue) but everybody seems happy to use git instead of svn so let's go

*Romain Manni-Bucau*
*Twitter: @rmannibucau *
*Blog: **http://rmannibucau.wordpress.com/*
*LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
*Github: https://github.com/rmannibucau*



2013/10/10 Gilles 

> On Thu, 10 Oct 2013 10:41:11 -0400, James Carman wrote:
>
>> All,
>>
>> We have had some great discussions about moving our SCM to Git.  I
>> think it's time to put it to a vote.  So, here we go:
>>
>> +1 - yes, move to Git
>> -1 - no, do not move to Git
>>
>
> -1
>
> Some people have indicated that this move might not address the problem
> it is supposed to. No conclusive answer has been provided.
>
>
> Regards,
> Gilles
>
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Moving to Git...

[Emmanuel Bourg]

-0

I'm fine with SVN and the time sucked by the migration could be better
spent coding the components (or reviewing the pending release candidates
*cough*). That said, Git is now well supported by the tools I use, so
I'm not opposed to the transition.

Emmanuel Bourg


Le 10/10/2013 16:41, James Carman a écrit :
> All,
> 
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
> 
> +1 - yes, move to Git
> -1 - no, do not move to Git
> 
> The vote will be left open for 72 hours.  Go!
> 
> James
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Moving to Git...

[Gary Gregory]

Could you please restart the thread with a [VOTE] in the subject?

Gary

On Thu, Oct 10, 2013 at 10:41 AM, James Carman
 wrote:
> All,
>
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
>
> +1 - yes, move to Git
> -1 - no, do not move to Git
>
> The vote will be left open for 72 hours.  Go!
>
> James
>
> -
> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [VOTE] Moving to Git...

[Emmanuel Bourg]

Le 10/10/2013 16:49, James Carman a écrit :
> I'm going to start another thread.  For me, in gmail, this got
> combined with the [DISCUSS] thread and I don't want votes to get lost.
>  Consider this [VOTE] canceled!  Romain, please vote again in the
> other thread.  Sorry, folks.

At least in Thunderbird the vote thread is distinct.

Emmanuel Bourg


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

Re: [VOTE] Moving to Git...

[James Carman]

Gary,

I actually did.  You have to show details in Gmail to see it.  For
some reason it collapsed the two threads.  Sorry for the confusion.
There's a new thread already started.

Thanks,

James

On Thu, Oct 10, 2013 at 10:57 AM, Gary Gregory  wrote:
> Could you please restart the thread with a [VOTE] in the subject?
>
> Gary
>
> On Thu, Oct 10, 2013 at 10:41 AM, James Carman
>  wrote:
>> All,
>>
>> We have had some great discussions about moving our SCM to Git.  I
>> think it's time to put it to a vote.  So, here we go:
>>
>> +1 - yes, move to Git
>> -1 - no, do not move to Git
>>
>> The vote will be left open for 72 hours.  Go!
>>
>> James
>>
>> -
>> 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
> JUnit in Action, Second Edition
> Spring Batch in Action
> 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
>

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

Re: [VOTE] Moving to Git...

[Emmanuel Bourg]

Le 10/10/2013 16:57, Gary Gregory a écrit :
> Could you please restart the thread with a [VOTE] in the subject?

There is one though:

http://www.mail-archive.com/dev@commons.apache.org/msg40574.html

Emmanuel Bourg


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

Re: [VOTE] Move Apache Commons to Git for SCM...

[Matt Benson]

On Thu, Oct 10, 2013 at 9:50 AM, James Carman wrote:

> All,
>
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
>
> +1 - yes, move to Git
> -1 - no, do not move to Git
>
>
+1 (binding)

Matt



> The vote will be left open for 72 hours.  Go!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Moving to Git...

[Jörg Schaible]

James Carman wrote:

> All,
> 
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
> 
> +1 - yes, move to Git
> -1 - no, do not move to Git
> 
> The vote will be left open for 72 hours.  Go!
> 
> James


-1

We have to ensure before that our tooling works with Git and that we stay 
compliant to ASF rules:

- Release from a Git branch (if we start increasing major versions more 
frequently, we will have soon the requirement for maintenance releases). 
AFAICS there are still problems for Maven.
- Someone raised the question about the shared stuff like site ... is that 
solved?
- Which Git server has the master? At Apache? At Github? If Github, legal 
consequences? If Apache, automated sync with Github?

No objection on the switch in general though.

Cheers,
Jörg




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

Re: [DISCUSS] Moving to Git...

[Ralph Goers]

Before I vote on this is someone volunteering to do the work? I assume Infra 
will take care of the actual move, but there are still web site links that have 
to be changed.

Ralph

On Oct 10, 2013, at 7:38 AM, James Carman  wrote:

> Well, we've had some lengthy discussions about this.  I think there is
> at least enough interest to put it up to a vote.  I'll start the
> thread here shortly.  We can continue the discussion on this thread so
> it doesn't get fragmented.
> 
> On Mon, Oct 7, 2013 at 10:10 PM, James Carman
>  wrote:
>> All,
>> 
>> If we did want to move to Git, we'd probably have to figure out how
>> we'd manage our "workflow" (couldn't think of a better word).  I
>> suppose we'd have a separate repo for each component?  What about
>> proper vs. sandbox?  How would we accommodate that paradigm?  Has
>> anyone else already gone through this thought process?  I must admit,
>> my git fu isn't what it should be.
>> 
>> James
> 
> -
> 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

Re: [VOTE] Move Apache Commons to Git for SCM...

[Mark Thomas]

On 10/10/2013 15:50, James Carman wrote:
> All,
> 
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
> 
> +1 - yes, move to Git
> -1 - no, do not move to Git
> 
> The vote will be left open for 72 hours.  Go!

-1. I'm not convinced that the implications have been fully thought
through (the web site has to remain on svn for example) nor that this
migration will solve the problems it aims to solve.

I'd be much happier with doing a trial with one component first before
starting a wholesale migration.

Mark


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

Re: [DISCUSS] Moving to Git...

[Matt Benson]

Those who vote +1 (contrast with +0) are beholden to assist where needed.
 :|

Matt


On Thu, Oct 10, 2013 at 10:04 AM, Ralph Goers wrote:

> Before I vote on this is someone volunteering to do the work? I assume
> Infra will take care of the actual move, but there are still web site links
> that have to be changed.
>
> Ralph
>
> On Oct 10, 2013, at 7:38 AM, James Carman 
> wrote:
>
> > Well, we've had some lengthy discussions about this.  I think there is
> > at least enough interest to put it up to a vote.  I'll start the
> > thread here shortly.  We can continue the discussion on this thread so
> > it doesn't get fragmented.
> >
> > On Mon, Oct 7, 2013 at 10:10 PM, James Carman
> >  wrote:
> >> All,
> >>
> >> If we did want to move to Git, we'd probably have to figure out how
> >> we'd manage our "workflow" (couldn't think of a better word).  I
> >> suppose we'd have a separate repo for each component?  What about
> >> proper vs. sandbox?  How would we accommodate that paradigm?  Has
> >> anyone else already gone through this thought process?  I must admit,
> >> my git fu isn't what it should be.
> >>
> >> James
> >
> > -
> > 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
>
>

Re: [VOTE] Moving to Git...

[James Carman]

The ASF has already set up "official" support for Git for their
projects.  These technical details have already been worked out.
There are MANY other projects using Git already (around 1/3 I
believe).

On Thu, Oct 10, 2013 at 11:04 AM, Jörg Schaible
 wrote:
> James Carman wrote:
>
>> All,
>>
>> We have had some great discussions about moving our SCM to Git.  I
>> think it's time to put it to a vote.  So, here we go:
>>
>> +1 - yes, move to Git
>> -1 - no, do not move to Git
>>
>> The vote will be left open for 72 hours.  Go!
>>
>> James
>
>
> -1
>
> We have to ensure before that our tooling works with Git and that we stay
> compliant to ASF rules:
>
> - Release from a Git branch (if we start increasing major versions more
> frequently, we will have soon the requirement for maintenance releases).
> AFAICS there are still problems for Maven.
> - Someone raised the question about the shared stuff like site ... is that
> solved?
> - Which Git server has the master? At Apache? At Github? If Github, legal
> consequences? If Apache, automated sync with Github?
>
> No objection on the switch in general though.
>
> Cheers,
> Jörg
>
>
>
>
> -
> 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

Re: [VFS] developer ping - future direction

[Ralph Goers]

I have been working primarily on Log4j 2 for a while.  I have always planned to 
come back to start work on VFS 3 that will integrate with Java 7's 
java.nio.file support.

Ralph


On Oct 9, 2013, at 10:38 AM, Bernd Eckenfels  wrote:

> Dear [VFS] Developer and Contributors,
> 
> Please excuse the spam (bcc to all emails mentioned as developers (8) or 
> contributors (6) in the project pom).
> 
> The project is currently a bit in sleeping state. I raised a few concerns and 
> questions on the commons-dev mailinglist and wanted to direct your attention 
> to the list - it would also help me to provide more patches when I know how 
> you would prefer to solve things I raised.
> 
> Could you maybe get ack to the list and let us know if you have any current 
> plans/needs with/for VFS2 and if you had looked at the recent VFS discussions 
> on the commons developer list.
> 
> Currently I am mostly concerend with concurrency and atomic transactions, but 
> also some unclear API meanings, dirty (commented out) code and the unit test 
> "suite" system is somewhat confusing to use if you want to write providers 
> outside of the main archive (with a -tests.jar dependency only).
> 
> I have two new providers, one which allows to project VFS on Blobs in a JDBC 
> table and one which simulates a virtual filesystem on top of git-style trees. 
> (https://github.com/ecki/seeburger-vfs2). For the former I need to implement 
> some atomicity and concurrency (for the content). And for the later some 
> questions around injecting the datasource and having additional fs operations 
> come to mind.
> 
> Besides that it might be time to think about 
> java.nio.file.spi.FileSystemProvider as well.
> 
> If you feel fluent in one of the points mentioned let me know. (if too much 
> discussion is coming out of that we can conser moving to an google group for 
> those, but for now it is just a dream that that could happen :)
> 
> What would be the quickest way for me to get acccess to the VFS wiki?
> 
> Greetings
> Bernd
> -- 
> http://www.zusammenkunft.net
> 
> -
> 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

Re: [VOTE] Moving to Git...

[Gary Gregory]

On Thu, Oct 10, 2013 at 11:04 AM, Jörg Schaible
 wrote:
> James Carman wrote:
>
>> All,
>>
>> We have had some great discussions about moving our SCM to Git.  I
>> think it's time to put it to a vote.  So, here we go:
>>
>> +1 - yes, move to Git
>> -1 - no, do not move to Git
>>
>> The vote will be left open for 72 hours.  Go!
>>
>> James
>
>
> -1
>
> We have to ensure before that our tooling works with Git and that we stay
> compliant to ASF rules:
>
> - Release from a Git branch (if we start increasing major versions more
> frequently, we will have soon the requirement for maintenance releases).
> AFAICS there are still problems for Maven.
> - Someone raised the question about the shared stuff like site ... is that
> solved?
> - Which Git server has the master? At Apache?

Of course at Apache. Why anywhere else? There are plenty of projects
already at git.apache.org that are mirrored to GitHub. There is an
established precedent. It looks Commons projects are mirrored from SVN
to our Git server already.

Gary

At Github? If Github, legal
> consequences? If Apache, automated sync with Github?
>
> No objection on the switch in general though.
>
> Cheers,
> Jörg
>
>
>
>
> -
> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [VOTE] Moving to Git...

[Gary Gregory]

On Thu, Oct 10, 2013 at 11:04 AM, Jörg Schaible
 wrote:
> James Carman wrote:
>
>> All,
>>
>> We have had some great discussions about moving our SCM to Git.  I
>> think it's time to put it to a vote.  So, here we go:
>>
>> +1 - yes, move to Git
>> -1 - no, do not move to Git
>>
>> The vote will be left open for 72 hours.  Go!
>>
>> James
>
>
> -1
>
> We have to ensure before that our tooling works with Git and that we stay
> compliant to ASF rules:
>
> - Release from a Git branch (if we start increasing major versions more
> frequently, we will have soon the requirement for maintenance releases).
> AFAICS there are still problems for Maven.

Great point. Sounds like someone needs to experiment and show that it
can be done. Since James started the vote,, perhaps he'd care to pick
one Commons component and try to release through git...

Gary

> - Someone raised the question about the shared stuff like site ... is that
> solved?
> - Which Git server has the master? At Apache? At Github? If Github, legal
> consequences? If Apache, automated sync with Github?
>
> No objection on the switch in general though.
>
> Cheers,
> Jörg
>
>
>
>
> -
> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [VOTE] Moving to Git...

[James Carman]

How is that any different than SVN?  We have to release from branches
with SVN too.  We don't copy our "maintenance" branches to trunk in
order to do releases.

On Thu, Oct 10, 2013 at 11:09 AM, Gary Gregory  wrote:
> On Thu, Oct 10, 2013 at 11:04 AM, Jörg Schaible
>  wrote:
>> James Carman wrote:
>>
>>> All,
>>>
>>> We have had some great discussions about moving our SCM to Git.  I
>>> think it's time to put it to a vote.  So, here we go:
>>>
>>> +1 - yes, move to Git
>>> -1 - no, do not move to Git
>>>
>>> The vote will be left open for 72 hours.  Go!
>>>
>>> James
>>
>>
>> -1
>>
>> We have to ensure before that our tooling works with Git and that we stay
>> compliant to ASF rules:
>>
>> - Release from a Git branch (if we start increasing major versions more
>> frequently, we will have soon the requirement for maintenance releases).
>> AFAICS there are still problems for Maven.
>
> Great point. Sounds like someone needs to experiment and show that it
> can be done. Since James started the vote,, perhaps he'd care to pick
> one Commons component and try to release through git...
>
> Gary
>
>> - Someone raised the question about the shared stuff like site ... is that
>> solved?
>> - Which Git server has the master? At Apache? At Github? If Github, legal
>> consequences? If Apache, automated sync with Github?
>>
>> No objection on the switch in general though.
>>
>> Cheers,
>> Jörg
>>
>>
>>
>>
>> -
>> 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
> JUnit in Action, Second Edition
> Spring Batch in Action
> 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
>

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

Re: [VOTE] Moving to Git...

[James Carman]

Sorry, didn't understand your question.  The Apache Camel team uses
Git and they release maintenance versions all the time (I believe
about 3 or 4 at a time sometimes when a bug fix gets merged down).
Here's a list of the current projects using Git:

https://git-wip-us.apache.org/repos/asf



On Thu, Oct 10, 2013 at 11:12 AM, James Carman
 wrote:
> How is that any different than SVN?  We have to release from branches
> with SVN too.  We don't copy our "maintenance" branches to trunk in
> order to do releases.
>
> On Thu, Oct 10, 2013 at 11:09 AM, Gary Gregory  wrote:
>> On Thu, Oct 10, 2013 at 11:04 AM, Jörg Schaible
>>  wrote:
>>> James Carman wrote:
>>>
 All,

 We have had some great discussions about moving our SCM to Git.  I
 think it's time to put it to a vote.  So, here we go:

 +1 - yes, move to Git
 -1 - no, do not move to Git

 The vote will be left open for 72 hours.  Go!

 James
>>>
>>>
>>> -1
>>>
>>> We have to ensure before that our tooling works with Git and that we stay
>>> compliant to ASF rules:
>>>
>>> - Release from a Git branch (if we start increasing major versions more
>>> frequently, we will have soon the requirement for maintenance releases).
>>> AFAICS there are still problems for Maven.
>>
>> Great point. Sounds like someone needs to experiment and show that it
>> can be done. Since James started the vote,, perhaps he'd care to pick
>> one Commons component and try to release through git...
>>
>> Gary
>>
>>> - Someone raised the question about the shared stuff like site ... is that
>>> solved?
>>> - Which Git server has the master? At Apache? At Github? If Github, legal
>>> consequences? If Apache, automated sync with Github?
>>>
>>> No objection on the switch in general though.
>>>
>>> Cheers,
>>> Jörg
>>>
>>>
>>>
>>>
>>> -
>>> 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
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> 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
>>

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

Re: [VOTE] Moving to Git...

[Jörg Schaible]

James Carman wrote:

> How is that any different than SVN?  We have to release from branches
> with SVN too.  We don't copy our "maintenance" branches to trunk in
> order to do releases.

The SCM providers in Maven were not written with Git in mind, the Git 
provider is quite new compared to mature Svn provider and there have been 
(also recently) reports form people that have problems to release from 
branch with Maven.

It's *not* a problem of Git, it might be a problem with the tooling.

- Jörg


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

[DISCUSS] Creating Project for Release Process Testing...

[James Carman]

Why don't we create a real project that we can cut real releases on to
test our release procedures?  Perhaps we can set it up so that it
doesn't sync with central and just gets staged locally.  This way, we
can test out changes to the release process and see how they work.
Also, a new release manager can play around with that project and get
it right before diving into the real work.

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

Re: [DISCUSS] Creating Project for Release Process Testing...

[Gary Gregory]

Nice idea, but push it to central to test the whole chain.

G

On Thu, Oct 10, 2013 at 11:24 AM, James Carman
 wrote:
> Why don't we create a real project that we can cut real releases on to
> test our release procedures?  Perhaps we can set it up so that it
> doesn't sync with central and just gets staged locally.  This way, we
> can test out changes to the release process and see how they work.
> Also, a new release manager can play around with that project and get
> it right before diving into the real work.
>
> -
> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [DISCUSS] Creating Project for Release Process Testing...

[Matt Benson]

Once it's properly in Nexus, is there any reason to push all the way to
central?

Matt


On Thu, Oct 10, 2013 at 10:29 AM, Gary Gregory wrote:

> Nice idea, but push it to central to test the whole chain.
>
> G
>
> On Thu, Oct 10, 2013 at 11:24 AM, James Carman
>  wrote:
> > Why don't we create a real project that we can cut real releases on to
> > test our release procedures?  Perhaps we can set it up so that it
> > doesn't sync with central and just gets staged locally.  This way, we
> > can test out changes to the release process and see how they work.
> > Also, a new release manager can play around with that project and get
> > it right before diving into the real work.
> >
> > -
> > 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
> JUnit in Action, Second Edition
> Spring Batch in Action
> 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
>
>

Re: [DISCUSS] Creating Project for Release Process Testing...

[James Carman]

Fine with me!  I'm good with that.  I just was worried folks would
think of it as "cluttering" central


On Thu, Oct 10, 2013 at 11:29 AM, Gary Gregory  wrote:
> Nice idea, but push it to central to test the whole chain.
>
> G
>
> On Thu, Oct 10, 2013 at 11:24 AM, James Carman
>  wrote:
>> Why don't we create a real project that we can cut real releases on to
>> test our release procedures?  Perhaps we can set it up so that it
>> doesn't sync with central and just gets staged locally.  This way, we
>> can test out changes to the release process and see how they work.
>> Also, a new release manager can play around with that project and get
>> it right before diving into the real work.
>>
>> -
>> 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
> JUnit in Action, Second Edition
> Spring Batch in Action
> 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
>

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

Re: [DISCUSS] Creating Project for Release Process Testing...

[Emmanuel Bourg]

Le 10/10/2013 17:24, James Carman a écrit :
> Why don't we create a real project that we can cut real releases on to
> test our release procedures?  Perhaps we can set it up so that it
> doesn't sync with central and just gets staged locally.  This way, we
> can test out changes to the release process and see how they work.
> Also, a new release manager can play around with that project and get
> it right before diving into the real work.

I'm not sure to see the need for this. There is no doubt Git is suitable
for releasing our components. I just walked down the release process for
JCI and besides for tagging I didn't have to interact much with SVN (I
didn't use the Maven release plugin).

With Git you would just have to create a branch, and push a commit that
changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
the same.

Emmanuel Bourg


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

Re: [DISCUSS] Creating Project for Release Process Testing...

[James Carman]

This isn't to address Git.  This is just in-general a little sandbox
that folks can use to either test out change to the release process
(or documentation) or just have a go at being a release manager before
actually volunteering.  Anyone would be free to cut a release at any
time.


On Thu, Oct 10, 2013 at 11:34 AM, Emmanuel Bourg  wrote:
> Le 10/10/2013 17:24, James Carman a écrit :
>> Why don't we create a real project that we can cut real releases on to
>> test our release procedures?  Perhaps we can set it up so that it
>> doesn't sync with central and just gets staged locally.  This way, we
>> can test out changes to the release process and see how they work.
>> Also, a new release manager can play around with that project and get
>> it right before diving into the real work.
>
> I'm not sure to see the need for this. There is no doubt Git is suitable
> for releasing our components. I just walked down the release process for
> JCI and besides for tagging I didn't have to interact much with SVN (I
> didn't use the Maven release plugin).
>
> With Git you would just have to create a branch, and push a commit that
> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
> the same.
>
> Emmanuel Bourg
>
>
> -
> 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

Re: [DISCUSS] Creating Project for Release Process Testing...

[Matt Benson]

Emmanuel,
  IMO this goes beyond the SCM question.  Commons releases are painful
(you've just been through the process; do you disagree?) and I submit that
this fact is the reason it takes so long for any of us to muster up the
courage to commit himself to diving into that process with no real idea
when he'll emerge.  Such a project would allow us to generalize and work
out the various "parts" that might be relevant to any Commons project and
could then serve as a cookbook to show how to address various situations.

Matt


On Thu, Oct 10, 2013 at 10:34 AM, Emmanuel Bourg  wrote:

> Le 10/10/2013 17:24, James Carman a écrit :
> > Why don't we create a real project that we can cut real releases on to
> > test our release procedures?  Perhaps we can set it up so that it
> > doesn't sync with central and just gets staged locally.  This way, we
> > can test out changes to the release process and see how they work.
> > Also, a new release manager can play around with that project and get
> > it right before diving into the real work.
>
> I'm not sure to see the need for this. There is no doubt Git is suitable
> for releasing our components. I just walked down the release process for
> JCI and besides for tagging I didn't have to interact much with SVN (I
> didn't use the Maven release plugin).
>
> With Git you would just have to create a branch, and push a commit that
> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
> the same.
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [DISCUSS] Creating Project for Release Process Testing...

[Emmanuel Bourg]

Le 10/10/2013 17:36, James Carman a écrit :
> This isn't to address Git.  This is just in-general a little sandbox
> that folks can use to either test out change to the release process
> (or documentation) or just have a go at being a release manager before
> actually volunteering.  Anyone would be free to cut a release at any
> time.

Ah sure, excellent idea. You may want two projects then, a simple one
and another with modules.

Emmanuel Bourg


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

Re: [DISCUSS] Creating Project for Release Process Testing...

[James Carman]

Or just a multi-module only and do the worst case scenario.

On Thu, Oct 10, 2013 at 11:41 AM, Emmanuel Bourg  wrote:
> Le 10/10/2013 17:36, James Carman a écrit :
>> This isn't to address Git.  This is just in-general a little sandbox
>> that folks can use to either test out change to the release process
>> (or documentation) or just have a go at being a release manager before
>> actually volunteering.  Anyone would be free to cut a release at any
>> time.
>
> Ah sure, excellent idea. You may want two projects then, a simple one
> and another with modules.
>
> Emmanuel Bourg
>
>
> -
> 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

Re: [DISCUSS] Creating Project for Release Process Testing...

[James Carman]

I need to have Matt start writing my emails. What he said! ;)  I'm too
impatient to be so eloquent.

On Thu, Oct 10, 2013 at 11:41 AM, Matt Benson  wrote:
> Emmanuel,
>   IMO this goes beyond the SCM question.  Commons releases are painful
> (you've just been through the process; do you disagree?) and I submit that
> this fact is the reason it takes so long for any of us to muster up the
> courage to commit himself to diving into that process with no real idea
> when he'll emerge.  Such a project would allow us to generalize and work
> out the various "parts" that might be relevant to any Commons project and
> could then serve as a cookbook to show how to address various situations.
>
> Matt
>
>
> On Thu, Oct 10, 2013 at 10:34 AM, Emmanuel Bourg  wrote:
>
>> Le 10/10/2013 17:24, James Carman a écrit :
>> > Why don't we create a real project that we can cut real releases on to
>> > test our release procedures?  Perhaps we can set it up so that it
>> > doesn't sync with central and just gets staged locally.  This way, we
>> > can test out changes to the release process and see how they work.
>> > Also, a new release manager can play around with that project and get
>> > it right before diving into the real work.
>>
>> I'm not sure to see the need for this. There is no doubt Git is suitable
>> for releasing our components. I just walked down the release process for
>> JCI and besides for tagging I didn't have to interact much with SVN (I
>> didn't use the Maven release plugin).
>>
>> With Git you would just have to create a branch, and push a commit that
>> changes the version (1.0-SNAPSHOT -> 1.0). The rest of the procedure is
>> the same.
>>
>> Emmanuel Bourg
>>
>>
>> -
>> 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

Re: [VOTE] Moving to Git...

[James Carman]

On Thu, Oct 10, 2013 at 10:50 AM, Gilles  wrote:
> -1
>
> Some people have indicated that this move might not address the problem
> it is supposed to. No conclusive answer has been provided.
>

What problem is that exactly?  Perhaps that's not well understood?

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

Re: [VOTE] Moving to Git...

[James Carman]

On Thu, Oct 10, 2013 at 11:09 AM, Gary Gregory  wrote:
>
> Great point. Sounds like someone needs to experiment and show that it
> can be done. Since James started the vote,, perhaps he'd care to pick
> one Commons component and try to release through git...
>

How about this?  I'm now on the Camel PMC.  How about I offer to be a
release manager for a maintenance release of Camel?  This way, I can
learn from a working git-based project about how they do it and bring
that knowledge back to us.  The instructions appear to just use the
standard maven release plugin.  We can "borrow" stuff from their Maven
setup of we want.

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

Re: [VOTE] Moving to Git...

[Gary Gregory]

On Thu, Oct 10, 2013 at 12:01 PM, James Carman
 wrote:
> On Thu, Oct 10, 2013 at 11:09 AM, Gary Gregory  wrote:
>>
>> Great point. Sounds like someone needs to experiment and show that it
>> can be done. Since James started the vote,, perhaps he'd care to pick
>> one Commons component and try to release through git...
>>
>
> How about this?  I'm now on the Camel PMC.  How about I offer to be a
> release manager for a maintenance release of Camel?  This way, I can
> learn from a working git-based project about how they do it and bring
> that knowledge back to us.  The instructions appear to just use the
> standard maven release plugin.  We can "borrow" stuff from their Maven
> setup of we want.

That sounds great!

Gary

>
> -
> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Apache Commons IRC Channel...

[James Carman]

As a reminder, we do have an IRC channel set up on freenode.  It's
#asfcommons.  Matt Benson and I are usually the only ones hanging out
there right now, but some of these discussions would go much faster if
we could discuss in real-time.  Of course, no decisions are made only
on IRC. If anything is discussed that we want to implement, we should
take it to the group on the mailing list first for discussion.

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

Re: Apache Commons IRC Channel...

[Matt Benson]

I'll add that any Commons PMC member registered on freenode should contact
one of us to be made a moderator of the IRC channel.

Matt


On Thu, Oct 10, 2013 at 11:15 AM, James Carman
wrote:

> As a reminder, we do have an IRC channel set up on freenode.  It's
> #asfcommons.  Matt Benson and I are usually the only ones hanging out
> there right now, but some of these discussions would go much faster if
> we could discuss in real-time.  Of course, no decisions are made only
> on IRC. If anything is discussed that we want to implement, we should
> take it to the group on the mailing list first for discussion.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Please? WAS: Re: [JCS] Asking for advice: separate CacheAccess and GroupCacheAccess?

[Thomas Vandahl]

On 03.10.13 13:30, Thomas Vandahl wrote:
> Hi folks,
> 
> I'd like to ask for suggestions for a problem solution regarding the
> typesafe handling of cache keys in JCS.
> 
> Previously, JCS was not aware of key and value types. So it was possible
> to mix cache elements having different key types within the same cache
> instance. This "feature" was abused to implement the cache groups, so
> that keys of e.g. type String were combined with keys of type GroupAttrName.
> 
> The current implementation implements this functionality by hacking
> around the generics type definitions (in all cache implementations)
> which is definitely not desirable. It also may cause ClassCastExceptions.
> 
> As I see it, it would be better to use some kind of decorator pattern
> for the GroupCacheAccess functions that wraps around a regular
> CacheAccess object. This would mean type-safety at the cost of major API
> changes. Also it would have the advantage that the cache implementations
> do not have to know about cache groups at all.
> 
> Are there better solutions? Other ideas how to resolve this?
> Your thoughts are very much appreciated.

No ideas? Really? Please help, I need a second opinion.

Bye, Thomas.



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

Re: [VOTE] Move Apache Commons to Git for SCM...

[Thomas Vandahl]

On 10.10.13 16:50, James Carman wrote:
> All,
> 
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
> 
> +1 - yes, move to Git
> -1 - no, do not move to Git

-1

I don't see any advantages.

Bye, Thomas.





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

Re: Please? WAS: Re: [JCS] Asking for advice: separate CacheAccess and GroupCacheAccess?

[Benedikt Ritter]

Sorry Thomas!!! I intended to have a look at this but then we started a lot
of discussions here. I just forgot it. I'll try to have a look!

Benedikt


2013/10/10 Thomas Vandahl 

> On 03.10.13 13:30, Thomas Vandahl wrote:
> > Hi folks,
> >
> > I'd like to ask for suggestions for a problem solution regarding the
> > typesafe handling of cache keys in JCS.
> >
> > Previously, JCS was not aware of key and value types. So it was possible
> > to mix cache elements having different key types within the same cache
> > instance. This "feature" was abused to implement the cache groups, so
> > that keys of e.g. type String were combined with keys of type
> GroupAttrName.
> >
> > The current implementation implements this functionality by hacking
> > around the generics type definitions (in all cache implementations)
> > which is definitely not desirable. It also may cause ClassCastExceptions.
> >
> > As I see it, it would be better to use some kind of decorator pattern
> > for the GroupCacheAccess functions that wraps around a regular
> > CacheAccess object. This would mean type-safety at the cost of major API
> > changes. Also it would have the advantage that the cache implementations
> > do not have to know about cache groups at all.
> >
> > Are there better solutions? Other ideas how to resolve this?
> > Your thoughts are very much appreciated.
>
> No ideas? Really? Please help, I need a second opinion.
>
> Bye, Thomas.
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [VOTE] Moving to Git...

[Jörg Schaible]

Hi James,

James Carman wrote:

> Sorry, didn't understand your question.  The Apache Camel team uses
> Git and they release maintenance versions all the time (I believe
> about 3 or 4 at a time sometimes when a bug fix gets merged down).
> Here's a list of the current projects using Git:
> 
> https://git-wip-us.apache.org/repos/asf

https://git-wip-us.apache.org/repos/asf?p=camel.git;a=heads

OK, this is an evidence that they are able to release from branch and they 
use the Maven release plugin. If they can manage, so can we.

- Jörg


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

Re: [VOTE] Move Apache Commons to Git for SCM...

[Benedikt Ritter]

+1 (binding)

we already have the mirrors for all proper components, so we probably will
only have to deal with sandbox and the site/build stuff.
I'll help where I can.


2013/10/10 James Carman 

> All,
>
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
>
> +1 - yes, move to Git
> -1 - no, do not move to Git
>
> The vote will be left open for 72 hours.  Go!
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter

Re: [VOTE] Release JCI 1.1 based on RC1

[James Carman]

+1, release it!

On Wed, Oct 9, 2013 at 11:21 AM, Emmanuel Bourg  wrote:
> This is a vote to release Apache Commons JCI 1.1 based on RC1.
>
> This is a bug fix release and an update to work with more recent
> versions of its dependencies.
>
>
> Tag:
> http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/ (r1530645)
>
> Release notes:
> http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/RELEASE-NOTES.txt
>
> Source and binary archives:
> http://people.apache.org/~ebourg/JCI-1.1RC1/dist/
>
> Site:
> http://people.apache.org/~ebourg/JCI-1.1RC1/site/
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapachecommons-151/
>
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
>   [ ] +1 Release it!
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you for your reviews,
>
> Emmanuel Bourg
>

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

Re: [VOTE] Move Apache Commons to Git for SCM...

[Damjan Jovanovic]

-1 (binding), it's a big change, so let's try Mark's idea of one
component first.



On Thu, Oct 10, 2013 at 5:06 PM, Mark Thomas  wrote:
> On 10/10/2013 15:50, James Carman wrote:
>> All,
>>
>> We have had some great discussions about moving our SCM to Git.  I
>> think it's time to put it to a vote.  So, here we go:
>>
>> +1 - yes, move to Git
>> -1 - no, do not move to Git
>>
>> The vote will be left open for 72 hours.  Go!
>
> -1. I'm not convinced that the implications have been fully thought
> through (the web site has to remain on svn for example) nor that this
> migration will solve the problems it aims to solve.
>
> I'd be much happier with doing a trial with one component first before
> starting a wholesale migration.
>
> Mark
>
>
> -
> 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

Re: [VOTE] Moving to Git...

[Bruno P. Kinoshita]

+1
 
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


- Original Message -
> From: James Carman 
> To: Commons Developers List 
> Cc: 
> Sent: Thursday, October 10, 2013 11:41 AM
> Subject: [VOTE] Moving to Git...
> 
> All,
> 
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
> 
> +1 - yes, move to Git
> -1 - no, do not move to Git
> 
> The vote will be left open for 72 hours.  Go!
> 
> James
> 
> -
> 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

Re: [VOTE] Move Apache Commons to Git for SCM...

[Bruno P. Kinoshita]

Looks like I've voted on the wrong thread, here's my vote

+1
 
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


- Original Message -
> From: James Carman 
> To: Commons Developers List 
> Cc: 
> Sent: Thursday, October 10, 2013 11:50 AM
> Subject: [VOTE] Move Apache Commons to Git for SCM...
> 
> All,
> 
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
> 
> +1 - yes, move to Git
> -1 - no, do not move to Git
> 
> The vote will be left open for 72 hours.  Go!
> 
> -
> 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

Re: [VOTE] Move Apache Commons to Git for SCM...

[Gary Gregory]

+1

Gary

On Thu, Oct 10, 2013 at 1:36 PM, Bruno P. Kinoshita
 wrote:
> Looks like I've voted on the wrong thread, here's my vote
>
> +1
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
> - Original Message -
>> From: James Carman 
>> To: Commons Developers List 
>> Cc:
>> Sent: Thursday, October 10, 2013 11:50 AM
>> Subject: [VOTE] Move Apache Commons to Git for SCM...
>>
>> All,
>>
>> We have had some great discussions about moving our SCM to Git.  I
>> think it's time to put it to a vote.  So, here we go:
>>
>> +1 - yes, move to Git
>> -1 - no, do not move to Git
>>
>> The vote will be left open for 72 hours.  Go!
>>
>> -
>> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [VOTE] Release JCI 1.1 based on RC1

[Gary Gregory]

On Thu, Oct 10, 2013 at 1:06 PM, James Carman
 wrote:
> +1, release it!

Really? What about binary compatibility? Call it 2.0 IMO. Now I'll be quiet ;)

Gary

>
> On Wed, Oct 9, 2013 at 11:21 AM, Emmanuel Bourg  wrote:
>> This is a vote to release Apache Commons JCI 1.1 based on RC1.
>>
>> This is a bug fix release and an update to work with more recent
>> versions of its dependencies.
>>
>>
>> Tag:
>> http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/ (r1530645)
>>
>> Release notes:
>> http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/RELEASE-NOTES.txt
>>
>> Source and binary archives:
>> http://people.apache.org/~ebourg/JCI-1.1RC1/dist/
>>
>> Site:
>> http://people.apache.org/~ebourg/JCI-1.1RC1/site/
>>
>> Maven artifacts:
>> https://repository.apache.org/content/repositories/orgapachecommons-151/
>>
>>
>> Please review the release candidate and vote.
>> This vote will close no sooner that 72 hours from now.
>>
>>   [ ] +1 Release it!
>>   [ ] +0 OK, but...
>>   [ ] -0 OK, but really should fix...
>>   [ ] -1 I oppose this release because...
>>
>> Thank you for your reviews,
>>
>> Emmanuel Bourg
>>
>
> -
> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [VOTE] Release JCI 1.1 based on RC1

[James Carman]

How many people are really using JCI?

On Thu, Oct 10, 2013 at 2:03 PM, Gary Gregory  wrote:
> On Thu, Oct 10, 2013 at 1:06 PM, James Carman
>  wrote:
>> +1, release it!
>
> Really? What about binary compatibility? Call it 2.0 IMO. Now I'll be quiet ;)
>
> Gary
>
>>
>> On Wed, Oct 9, 2013 at 11:21 AM, Emmanuel Bourg  wrote:
>>> This is a vote to release Apache Commons JCI 1.1 based on RC1.
>>>
>>> This is a bug fix release and an update to work with more recent
>>> versions of its dependencies.
>>>
>>>
>>> Tag:
>>> http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/ (r1530645)
>>>
>>> Release notes:
>>> http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/RELEASE-NOTES.txt
>>>
>>> Source and binary archives:
>>> http://people.apache.org/~ebourg/JCI-1.1RC1/dist/
>>>
>>> Site:
>>> http://people.apache.org/~ebourg/JCI-1.1RC1/site/
>>>
>>> Maven artifacts:
>>> https://repository.apache.org/content/repositories/orgapachecommons-151/
>>>
>>>
>>> Please review the release candidate and vote.
>>> This vote will close no sooner that 72 hours from now.
>>>
>>>   [ ] +1 Release it!
>>>   [ ] +0 OK, but...
>>>   [ ] -0 OK, but really should fix...
>>>   [ ] -1 I oppose this release because...
>>>
>>> Thank you for your reviews,
>>>
>>> Emmanuel Bourg
>>>
>>
>> -
>> 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
> JUnit in Action, Second Edition
> Spring Batch in Action
> 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
>

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

Re: [VOTE] Release JCI 1.1 based on RC1

[Stefan Bodewig]

On 2013-10-09, Emmanuel Bourg wrote:

> This is a vote to release Apache Commons JCI 1.1 based on RC1.

I feel incredibly sorry for having to bring up something that looks like
a minor detail - the copyright year in NOTICE doesn't extend to 2013.

IANAL and all that but I'd feel more comfortable to cast a +1 if this
was fixed - in fact I've already made the trivial change in trunk.

Other than that I've done the usual formal vetting and things look good
to me.  I don't know JCI's internals so won't try to judge the release
based on its content.

Stefan

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

Re: [VOTE] Release JCI 1.1 based on RC1

[Gary Gregory]

On Thu, Oct 10, 2013 at 2:10 PM, James Carman
 wrote:
> How many people are really using JCI?

All it takes to create jar hell is one project using it which is then
a dependent of a popular project :(

What's the big deal about bumping to 2.0? You get all the API
deletion, additions and twiddling you want and none of the calories!

Gary
>
> On Thu, Oct 10, 2013 at 2:03 PM, Gary Gregory  wrote:
>> On Thu, Oct 10, 2013 at 1:06 PM, James Carman
>>  wrote:
>>> +1, release it!
>>
>> Really? What about binary compatibility? Call it 2.0 IMO. Now I'll be quiet 
>> ;)
>>
>> Gary
>>
>>>
>>> On Wed, Oct 9, 2013 at 11:21 AM, Emmanuel Bourg  wrote:
 This is a vote to release Apache Commons JCI 1.1 based on RC1.

 This is a bug fix release and an update to work with more recent
 versions of its dependencies.


 Tag:
 http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/ (r1530645)

 Release notes:
 http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/RELEASE-NOTES.txt

 Source and binary archives:
 http://people.apache.org/~ebourg/JCI-1.1RC1/dist/

 Site:
 http://people.apache.org/~ebourg/JCI-1.1RC1/site/

 Maven artifacts:
 https://repository.apache.org/content/repositories/orgapachecommons-151/


 Please review the release candidate and vote.
 This vote will close no sooner that 72 hours from now.

   [ ] +1 Release it!
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

 Thank you for your reviews,

 Emmanuel Bourg

>>>
>>> -
>>> 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
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> 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
>>
>
> -
> 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
JUnit in Action, Second Edition
Spring Batch in Action
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

Re: [VOTE] Release JCI 1.1 based on RC1

[Emmanuel Bourg]

Le 10/10/2013 20:12, Stefan Bodewig a écrit :

> I feel incredibly sorry for having to bring up something that looks like
> a minor detail - the copyright year in NOTICE doesn't extend to 2013.
> 
> IANAL and all that but I'd feel more comfortable to cast a +1 if this
> was fixed - in fact I've already made the trivial change in trunk.
> 
> Other than that I've done the usual formal vetting and things look good
> to me.  I don't know JCI's internals so won't try to judge the release
> based on its content.

Thank you Stefan, I missed that one. The NOTICE.txt in the jars already
have the right date.

Emmanuel Bourg


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

Re: [VOTE] Release JCI 1.1 based on RC1

[Emmanuel Bourg]

Le 10/10/2013 20:03, Gary Gregory a écrit :

> Really? What about binary compatibility? Call it 2.0 IMO. Now I'll be quiet ;)

Gary, it *is* binary compatible. We are just no longer releasing the
module commons-jci-javac. But you can still mix the released
commons-jci-javac 1.0 with the upcoming commons-jci-core 1.1

Emmanuel Bourg


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

Re: [VOTE] Release JCI 1.1 based on RC1

[James Carman]

FYI, trunk has been "upgraded" to 2.0 in case that's where we go with
this.  If not, feel free to back it out.

On Thu, Oct 10, 2013 at 2:18 PM, Gary Gregory  wrote:
> On Thu, Oct 10, 2013 at 2:10 PM, James Carman
>  wrote:
>> How many people are really using JCI?
>
> All it takes to create jar hell is one project using it which is then
> a dependent of a popular project :(
>
> What's the big deal about bumping to 2.0? You get all the API
> deletion, additions and twiddling you want and none of the calories!
>
> Gary
>>
>> On Thu, Oct 10, 2013 at 2:03 PM, Gary Gregory  wrote:
>>> On Thu, Oct 10, 2013 at 1:06 PM, James Carman
>>>  wrote:
 +1, release it!
>>>
>>> Really? What about binary compatibility? Call it 2.0 IMO. Now I'll be quiet 
>>> ;)
>>>
>>> Gary
>>>

 On Wed, Oct 9, 2013 at 11:21 AM, Emmanuel Bourg  wrote:
> This is a vote to release Apache Commons JCI 1.1 based on RC1.
>
> This is a bug fix release and an update to work with more recent
> versions of its dependencies.
>
>
> Tag:
> http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/ 
> (r1530645)
>
> Release notes:
> http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/RELEASE-NOTES.txt
>
> Source and binary archives:
> http://people.apache.org/~ebourg/JCI-1.1RC1/dist/
>
> Site:
> http://people.apache.org/~ebourg/JCI-1.1RC1/site/
>
> Maven artifacts:
> https://repository.apache.org/content/repositories/orgapachecommons-151/
>
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
>   [ ] +1 Release it!
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
>
> Thank you for your reviews,
>
> Emmanuel Bourg
>

 -
 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
>>> JUnit in Action, Second Edition
>>> Spring Batch in Action
>>> 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
>>>
>>
>> -
>> 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
> JUnit in Action, Second Edition
> Spring Batch in Action
> 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
>

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

Re: [VOTE] Move Apache Commons to Git for SCM...

[Luc Maisonobe]

Le 10/10/2013 19:27, Damjan Jovanovic a écrit :
> -1 (binding), it's a big change, so let's try Mark's idea of one
> component first.

+1. I see a lot of advantages. The first one is in branches merging
which could help for experimental stuff, the second is in getting
contributions (for example large ones like that of Evan), and the third
is in the use tooling.

But I also agree a first step with one component would be easier for
most people. Git is not simple to learn.

Luc


> 
> 
> 
> On Thu, Oct 10, 2013 at 5:06 PM, Mark Thomas  wrote:
>> On 10/10/2013 15:50, James Carman wrote:
>>> All,
>>>
>>> We have had some great discussions about moving our SCM to Git.  I
>>> think it's time to put it to a vote.  So, here we go:
>>>
>>> +1 - yes, move to Git
>>> -1 - no, do not move to Git
>>>
>>> The vote will be left open for 72 hours.  Go!
>>
>> -1. I'm not convinced that the implications have been fully thought
>> through (the web site has to remain on svn for example) nor that this
>> migration will solve the problems it aims to solve.
>>
>> I'd be much happier with doing a trial with one component first before
>> starting a wholesale migration.
>>
>> Mark
>>
>>
>> -
>> 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
> 
> 


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

Re: [VOTE] Move Apache Commons to Git for SCM...

[James Carman]

We could migrate our new release testing project (commons-canary :)
first.  Get the kinks worked out using it.  Then, we migrate the rest
of the projects.

On Thu, Oct 10, 2013 at 3:13 PM, Luc Maisonobe  wrote:
> Le 10/10/2013 19:27, Damjan Jovanovic a écrit :
>> -1 (binding), it's a big change, so let's try Mark's idea of one
>> component first.
>
> +1. I see a lot of advantages. The first one is in branches merging
> which could help for experimental stuff, the second is in getting
> contributions (for example large ones like that of Evan), and the third
> is in the use tooling.
>
> But I also agree a first step with one component would be easier for
> most people. Git is not simple to learn.
>
> Luc
>
>
>>
>>
>>
>> On Thu, Oct 10, 2013 at 5:06 PM, Mark Thomas  wrote:
>>> On 10/10/2013 15:50, James Carman wrote:
 All,

 We have had some great discussions about moving our SCM to Git.  I
 think it's time to put it to a vote.  So, here we go:

 +1 - yes, move to Git
 -1 - no, do not move to Git

 The vote will be left open for 72 hours.  Go!
>>>
>>> -1. I'm not convinced that the implications have been fully thought
>>> through (the web site has to remain on svn for example) nor that this
>>> migration will solve the problems it aims to solve.
>>>
>>> I'd be much happier with doing a trial with one component first before
>>> starting a wholesale migration.
>>>
>>> Mark
>>>
>>>
>>> -
>>> 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
>>
>>
>
>
> -
> 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

Re: [VOTE] Move Apache Commons to Git for SCM...

[Phil Steitz]

The "binding" annotations on this thread kind of bug me here - we
should be deciding this kind of thing by community consensus. 
"Binding" is only meaningful in release votes and VOTE-ing in
general should be a last resort rather than early step in getting to
consensus.  I have tried to keep up with the threads but have yet to
see a really clear rationale for the move.  It would help me
personally get on board with allocating some of my own scarce
volunteering time to this if I someone could summarize what exactly
we will get out of it.

Phil

On 10/10/13 7:50 AM, James Carman wrote:
> All,
>
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
>
> +1 - yes, move to Git
> -1 - no, do not move to Git
>
> The vote will be left open for 72 hours.  Go!
>
> -
> 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

Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases [Was: [DISCUSS] Putting several unmaintained components to dormant]

[Rahul Akolkar]

On Thu, Oct 10, 2013 at 7:26 AM, Ate Douma  wrote:
> I've move this into a separate [DISCUSS] thread as I think it needs separate
> discussion.
>
> Jörg gave some objections below about using Milestone releases, as I
> proposed earlier to support releasing intermediate versions of a
> not-yet-stabalized component.
>
> While I understand his problems with unstable versions potentially getting
> 'stuck' for long time, where end-users *might* start expecting them to
> remain stable, I don't agree this is, or should be, the common case. Or at
> least not an argument to hold against using such 0.x or -Milestone releases.
>
> Instead, the whole point is to get project/component development moving
> *faster* by allowing *experimental* end-users to provide feedback, and more
> flexibility and convenience for the developers of such project/component.
>
> The idea to have to 'switch' to a next major version for any incompatibile
> change, as Jörg proposes, requiring package changes, whatnot, while a
> project clearly is not ready to stabalize, really puts way too much hurdles
> up for both the developers *and* such experimental end-users, as they would
> HAVE to change all of their code to be able to provide AND leaverage such
> new 0.x or Milestone version.
>
> Case in point: SCXML
> If we are allowed to start working on this component shortly, we intend to,
> and HAVE to switch to a 1.0 version first, as there already is a 0.9 version
> release out, while we will need to move to newer JDK and incompatible API
> changes anyway. At the same time, getting a final/stabalized 1.0 release out
> most certainly will take several iterations.


Release version comparisons being what the are, we could go to v0.10,
as in below (greater than sign implies more recent release version):

0.11 > 0.10 > 0.9

Not very different than, say the following, which may appear more
intuitive for release versions (agree 0.x line is trickier):

2.11 > 2.10 > 2.9

Overall, I think it's OK to go the 0.10 route, if you want to save a
1.0 major release for later at a point it's really needed.

In hindsight, the first Commons SCXML release could've been 0.1
(rather than 0.5) to give more room for 4 more releases before getting
to this point :-)

-Rahul



> I don't want to have to wait doing an intermediate release, nor rapidly
> having to switch to a 2.x/3.x/4.x/etc. versions, just because Milestone
> releases are acceptable for this purpose. Where would Milestone releases [1]
> be useful for otherwise, anyway?
>
> I think a real problem might arise IF other components (or 3rd party
> libraries) would start depending directly on such Milestone releases,
> potentially introducing unexpected instabilities for end-users. And maybe it
> is worthwhile to make such usages, at least for Commons, prohibited. That
> would make sense to me.
>
> But for components like SCXML, javaflow, or csv, this I don't think would be
> a real issue. Those end-users making use of these experimental components
> are, or should be very well aware, of the added responsibility they take
> depending on a not-yet-stabilized version, as clearly is also indicated by
> the version, as well as SHOULD be prominently documented in the release
> notes, readme, etc.
>
> Thoughts?
>
> Ate
>
> On 10/10/2013 12:45 PM, Benedikt Ritter wrote:
>>
>> I like the idea of releasing 0.x versions. A good example is [csv]. I
>> would have no problem with releasing the current trunk as 0.9. At the moment
>> [csv] is just another component we don't releaese because we want to come up
>> with a perfect API (and I take responsibility for that :-)
>>
>> Benedikt
>>
>> Send from my mobile device
>>
>>> Am 10.10.2013 um 12:15 schrieb Jörg Schaible
>>> :
>>>
>>> Hi,
>>>
>>> Ate Douma wrote:
>>>
> On 10/10/2013 12:24 AM, Torsten Curdt wrote:
> Every now and then I keep getting requests via private mail asking to
> release javaflow as it seems to be working for people. Yet I know there
> is still so much essential stuff to fix for a 1.0 release.
>
> Crossing over to the other thread: I know on github I would made a 0.x
> release already ages ago but knowing I won't have time to work on it
> anymore I keep pushing this out at commons.


 Wouldn't this be a case to allow and use intermediate milestone
 releases?

 Using a 1.0-Mxx version would make still clear to the users things
 haven't
 settled yet (API wise), so should not limit or restrict making API
 changes
 before a final 1.0 release, but would help both the community and the
 project moving. More likely to incite further involvement and
 contributions, etc.

 Being 'stuck' on getting a (final) 1.0 release out because everything
 should be settled and 'frozen' (API wise) first doesn't make sense to me
 at all.
>>>
>>>
>>> We should not be so afraid to switch to 2.x if the 1.x API turns out to
>>> be
>>> cumbersome in some cases. Typically you may also incre

Re: [DISCUSS] Putting several unmaintained components to dormant

[Oliver Heger]

Am 09.10.2013 21:17, schrieb Benedikt Ritter:
> Hi,
> 
> I think Phil came up with the idea to try to focus on the components that
> we are able to maintain and put all other stuff to dormant. Here is the
> list of components that I think really are proper:
> 
> - CLI
> - Codec
> - Collections
> - Compress
> - Configuration
> - CSV
> - Daemon
> - DBCP (?)
> - Email
> - Functor
> - Imaging (?)
> - IO
> - JCI
> - Lang
> - Logging
> - Math
> - Net
> - Pool (?)
> - Proxy
> - SCXML (after recent interest)
> - VFS
> - Weaver
> 
> All other stuff can go dormant because there is currently nobody who
> maintains it. Still a pretty long list. Thoughts? Anything missing?

I would like to get another release of BeanUtils out because there is a
dependency to the current work on Configuration. After that I am
interested in working on BeanUtils2 (in the sandbox).

Oliver

> 
> Benedikt
> 


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

Re: [VOTE] Move Apache Commons to Git for SCM...

[Oliver Heger]

+1 to git in general, however, I also prefer the approach to do the move
in a more careful way, i.e. experimenting with single components first.

Oliver

Am 10.10.2013 16:50, schrieb James Carman:
> All,
> 
> We have had some great discussions about moving our SCM to Git.  I
> think it's time to put it to a vote.  So, here we go:
> 
> +1 - yes, move to Git
> -1 - no, do not move to Git
> 
> The vote will be left open for 72 hours.  Go!
> 
> -
> 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

Re: [LANG] Build fails with JDK 8 developer preview

[Matt Benson]

Fixed the compile error, however I get some test errors:

Results :

Failed tests:
  FastDateFormat_ParserTest>FastDateParserTest.testParseZone:118
expected: but was:
  FastDateParserTest.testParseZone:118 expected: but was:

Tests in error:
  LocaleUtilsTest.testParseAllLocales:570 » IllegalArgument Invalid locale
forma...


Any ideas?

Matt




On Mon, Aug 12, 2013 at 1:51 PM, Benedikt Ritter  wrote:

> Hi,
>
> I've been playing around with developer previews of JDK 8 lately and I just
> realized that LANG does not build with JDK 8. This may not be super
> critical but I thought better to be aware of this early instead of being
> caught off guard.
>
> Here is some info about my system and the complete log of mvn clean test:
>
> localhost:lang bene$ java -version
> java version "1.8.0-ea"
> Java(TM) SE Runtime Environment (build 1.8.0-ea-b102)
> Java HotSpot(TM) 64-Bit Server VM (build 25.0-b44, mixed mode)
>
> localhost:lang bene$ mvn -version
> Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 2013-02-19
> 14:51:28+0100)
> Maven home: /Applications/dev/maven/apache-maven-3.0.5
> Java version: 1.8.0-ea, vendor: Oracle Corporation
> Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0.jdk/Contents/Home/jre
> Default locale: de_DE, platform encoding: UTF-8
> OS name: "mac os x", version: "10.8.4", arch: "x86_64", family: "mac"
>
> localhost:lang bene$ mvn clean test
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO]
> 
> [INFO] Building Commons Lang 3.2-SNAPSHOT
> [INFO]
> 
> [INFO]
> [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ commons-lang3 ---
> [INFO] Deleting /Users/bene/workspace/apache/commons/lang/target
> [INFO]
> [INFO] --- maven-antrun-plugin:1.7:run (javadoc.resources) @ commons-lang3
> ---
> [INFO] Executing tasks
>
> main:
>  [copy] Copying 2 files to
> /Users/bene/workspace/apache/commons/lang/target/apidocs/META-INF
> [INFO] Executed tasks
> [INFO]
> [INFO] --- maven-remote-resources-plugin:1.4:process (default) @
> commons-lang3 ---
> [INFO]
> [INFO] --- buildnumber-maven-plugin:1.2:create (default) @ commons-lang3
> ---
> [INFO] Checking for local modifications: skipped.
> [INFO] Updating project files from SCM: skipped.
> [INFO] Executing: /bin/sh -c cd /Users/bene/workspace/apache/commons/lang
> && svn --non-interactive info
> [INFO] Working directory: /Users/bene/workspace/apache/commons/lang
> [INFO] Storing buildNumber: 1512811 at timestamp: 137611755
> [INFO] Executing: /bin/sh -c cd /Users/bene/workspace/apache/commons/lang
> && svn --non-interactive info
> [INFO] Working directory: /Users/bene/workspace/apache/commons/lang
> [INFO] Storing buildScmBranch: trunk
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @
> commons-lang3 ---
> [INFO] Using 'ISO-8859-1' encoding to copy filtered resources.
> [INFO] Copying 0 resource
> [INFO] Copying 2 resources to META-INF
> [INFO]
> [INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @
> commons-lang3 ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 108 source files to
> /Users/bene/workspace/apache/commons/lang/target/classes
> [INFO]
> [INFO] --- maven-bundle-plugin:2.3.7:manifest (bundle-manifest) @
> commons-lang3 ---
> [INFO]
> [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources)
> @ commons-lang3 ---
> [INFO] Using 'ISO-8859-1' encoding to copy filtered resources.
> [INFO] Copying 2 resources
> [INFO] Copying 2 resources to META-INF
> [INFO]
> [INFO] --- maven-compiler-plugin:3.0:testCompile (default-testCompile) @
> commons-lang3 ---
> [INFO] Changes detected - recompiling the module!
> [INFO] Compiling 129 source files to
> /Users/bene/workspace/apache/commons/lang/target/test-classes
> [INFO] -
> [ERROR] COMPILATION ERROR :
> [INFO] -
> [ERROR]
>
> /Users/bene/workspace/apache/commons/lang/src/test/java/org/apache/commons/lang3/reflect/TypeUtilsTest.java:[530,47]
> incompatible types: inferred type does not conform to upper bound(s)
> inferred: G
> upper bound(s): java.lang.Comparable,java.lang.Integer
> [INFO] 1 error
> [INFO] -
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 7.467s
> [INFO] Finished at: Mon Aug 12 20:48:38 CEST 2013
> [INFO] Final Memory: 28M/446M
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.0:testCompile
> (default-testCompile) on project commons-lang3: Compilation failure
> [ERR

Re: [VOTE] Moving to Git...

[James Carman]

An interesting bit of stats for the Apache Camel project.  Here's
their pull request history:

Jan 3
Feb 4
Mar 6
Apr 1
May 2
Jun 4
Jul 10
Aug 6
Sep 4

They switched their repository over to Git in May.  So, for the 4
months before May, they had a total of 14 pull requests.  For the 4
months after May, they've had 24.  Definitely not scientific, but it's
interesting.

On Thu, Oct 10, 2013 at 1:28 PM, Bruno P. Kinoshita
 wrote:
> +1
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
> - Original Message -
>> From: James Carman 
>> To: Commons Developers List 
>> Cc:
>> Sent: Thursday, October 10, 2013 11:41 AM
>> Subject: [VOTE] Moving to Git...
>>
>> All,
>>
>> We have had some great discussions about moving our SCM to Git.  I
>> think it's time to put it to a vote.  So, here we go:
>>
>> +1 - yes, move to Git
>> -1 - no, do not move to Git
>>
>> The vote will be left open for 72 hours.  Go!
>>
>> James
>>
>> -
>> 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
>

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

Re: [VOTE] Release JCI 1.1 based on RC1

[Matt Benson]

LICENSE and NOTICE files are present in source archive, as well as source
and "artifact" jars for each module, but absent in test, test-sources and
javadoc jars.  Rules on LICENSE and NOTICE files are a little fuzzy for
convenience binaries, so not a blocker IMO.

Hashes match, PGP sigs check out, source jar builds and installs for me.

+1

Matt


On Thu, Oct 10, 2013 at 1:56 PM, James Carman wrote:

> FYI, trunk has been "upgraded" to 2.0 in case that's where we go with
> this.  If not, feel free to back it out.
>
> On Thu, Oct 10, 2013 at 2:18 PM, Gary Gregory 
> wrote:
> > On Thu, Oct 10, 2013 at 2:10 PM, James Carman
> >  wrote:
> >> How many people are really using JCI?
> >
> > All it takes to create jar hell is one project using it which is then
> > a dependent of a popular project :(
> >
> > What's the big deal about bumping to 2.0? You get all the API
> > deletion, additions and twiddling you want and none of the calories!
> >
> > Gary
> >>
> >> On Thu, Oct 10, 2013 at 2:03 PM, Gary Gregory 
> wrote:
> >>> On Thu, Oct 10, 2013 at 1:06 PM, James Carman
> >>>  wrote:
>  +1, release it!
> >>>
> >>> Really? What about binary compatibility? Call it 2.0 IMO. Now I'll be
> quiet ;)
> >>>
> >>> Gary
> >>>
> 
>  On Wed, Oct 9, 2013 at 11:21 AM, Emmanuel Bourg 
> wrote:
> > This is a vote to release Apache Commons JCI 1.1 based on RC1.
> >
> > This is a bug fix release and an update to work with more recent
> > versions of its dependencies.
> >
> >
> > Tag:
> > http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/(r1530645)
> >
> > Release notes:
> >
> http://svn.apache.org/repos/asf/commons/proper/jci/tags/1.1-RC1/RELEASE-NOTES.txt
> >
> > Source and binary archives:
> > http://people.apache.org/~ebourg/JCI-1.1RC1/dist/
> >
> > Site:
> > http://people.apache.org/~ebourg/JCI-1.1RC1/site/
> >
> > Maven artifacts:
> >
> https://repository.apache.org/content/repositories/orgapachecommons-151/
> >
> >
> > Please review the release candidate and vote.
> > This vote will close no sooner that 72 hours from now.
> >
> >   [ ] +1 Release it!
> >   [ ] +0 OK, but...
> >   [ ] -0 OK, but really should fix...
> >   [ ] -1 I oppose this release because...
> >
> > Thank you for your reviews,
> >
> > Emmanuel Bourg
> >
> 
>  -
>  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
> >>> JUnit in Action, Second Edition
> >>> Spring Batch in Action
> >>> 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
> >>>
> >>
> >> -
> >> 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
> > JUnit in Action, Second Edition
> > Spring Batch in Action
> > 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
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>