commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <>
Subject [VFS][ALL] dependency version handling
Date Fri, 24 Jun 2005 18:57:17 GMT
Hi all!

I'll try again to discuss it, that times with a more concrete plan.

First: Due to the nature of VFS we have a public API (the VFS API) and a 
private API - the API used to talk to our dependencies.

I would like to outline a plan how to deal with release changes:

public API: As always, changes which are not backward compatible need 
two .0 releases.
e.g. 1.0 - 2.0 deprecation - 3.0 deletion

private API/dependencies: We need a different way for them.
A version change which is backward compatible happens silently (in fact 
I will state them in our release_notes) - no one is forced to go the way 
with us.

More interresting is the part where the version change of a dependency 
is NOT backward compatible.

I propose to start a VOTE at commons-dev and commons-user where we state 
why we need this upgrade, but allow others to veto it.
Other than our common votes I would like to give voting rights to users 
too. A vote passed if 2/3 of all votes are positive.
A negative vote delays its upgrade to the next release (regardless if 
its a major release) and requires a new VOTE.

What do you think?


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

View raw message