[VFS][ALL] dependency version handling

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[VFS][ALL] dependency version handling

Mario Ivankovits
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: [hidden email]
For additional commands, e-mail: [hidden email]