directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephane Bailliez <>
Subject Re: [release][VOTE] Releasing MINA 0.7.1
Date Sun, 22 May 2005 17:33:20 GMT
Alex Karasulu wrote:

> No you are not whining!  Please don't feel like anyone is going to 
> haze ya.  Its a wise thing to do.  If you are working on a project 
> within this community that affects others you should make sure you are 
> not breaking code in other projects.  Or at least drop a big [WARNING] 
> email onto the list.  That goes for all of us.  This is the minimum I 
> would expect.  Better yet just make the necessary fixes to the 
> protocol-providers really quick - but MINA committers are not obliged 
> to do this.  The [WARNING] is enough. We need projects to compile one 
> way or another just so we don't get caught with our pants down ;).

Having a message like "WARNING - I just changed the whole API, it's up 
to you to sort out everything now" may be the minimum...but won't help 
much.. except make you breath  the 4 letter word another time. :)

> However note that releasing MINA should not be contingent on wether or 
> not a protocol-provider works within its trunk.  That means we need to 
> fix the p-p.  At this point we can start depending on the last stable 
> release before we upgrade our dependent projects.  Or just learn how 
> to take a timestamped SNAPSHOT which has very different semantics in 
> Mave.  I do not want to hold the MINA folks back from changing the API 
> even if those changes are dramatic before a 1.0 is released.  If a 1.0 
> is out I would expect smooth, gentle deprecation as is expected of a 
> mature API.
> So IMHO I don't believe in deprication when it comes to sub 1.0 APIs.  
> I think they could fly by the seat of their pants giving us surprises 
> if they need to.  Yah MINA people can yank stuff or put new stuff in 
> without having to consider breakage or deprecation.  It's up to the 
> users to take *time stamped* SNAPSHOTs if they do not want surprises 
> or to stick to a stable release.

I agree that while a component does not reach a 1.0, public API is 
subject to change anytime. During these time, we are normally still 
somewhat looking for the best API, add a better semantic, etc... and 
adding deprecation may add a bit of an unecessary overhead.

However when the component is part of an application it resides within, 
there are extra care to take about. For sure.

> Understand that Directory is not another level of the incubator to 
> graduate from.  However at the same time we must balance this with the 
> fact these projects actually are distinct although needed by directory 
> services.  They can exist on their own if the community and product 
> matures enough.  Look at Tomcat.  Only within the past month has it 
> asked to go the route of TLP instead of staying in the massive Jakarta 
> TLP.

It's a bit different and the reason they did not go to the TLP route 
before was apparently because they had more important things to care 
about than moving everything. If you want to take an example for Tomcat, 
just keep in mind that Ant and Digester for example were initially part 
of the Tomcat code. As for the commons, you don't need to have the same 
prerequisites than for any other project.

I think Emmanuel is right that MINA and ASN1 will ultimately probably 
find a better place at commons than at Directory.
Maybe not now, but not that far from now. They both have a much wider 
audience than Directory as they are components.

> Let's just keep working hard to make everything better.  Good things 
> will happen both for the projects here and the foundation naturally 
> without forcing a fit.  The ASF leadership will always try to do what 
> is best to foster the best circumstances for both the foundation and 
> individual projects.
> o a CI system that works and does not require me to know python or 
> movie character names ;)

I have found BeetleJuice[1] to work quite well for now.
I installed it recently at work to monitor some projects. It takes only 
a couple of minutes to setup


View raw message