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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
