[VFS][ALL] dependency version handling

[Mario Ivankovits <ma...@ops.co.at>]

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?

---
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org

Re: [VFS][ALL] dependency version handling

[Martin Cooper <mf...@gmail.com>]

My first reaction is that cross-posting is bad e-mail etiquette. My
second reaction is that users do not get votes. I think it would be
fine if you want to take a *poll* on the user list to see what people
think, post the results to the dev list, and perhaps follow up with a
vote on the dev list only. That way, the vote by the developers is
informed by the opinions of the users.

--
Martin Cooper


On 6/24/05, Mario Ivankovits <ma...@ops.co.at> wrote:
> 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?
> 
> ---
> Mario
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
>

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