commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [DISCUSS] Allow unstable 0.x OR -Milestone releases
Date Thu, 10 Oct 2013 12:25:32 GMT
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.<componentname><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).

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 

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:


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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message