About Feature enhancement Updates Policy
sebelk at gmail.com
Mon Sep 26 14:42:14 UTC 2011
2011/9/25 Kevin Fenzi <kevin at scrye.com>:
> On Sun, 25 Sep 2011 15:19:45 -0300
> Sergio Belkin <sebelk at gmail.com> wrote:
>> I've read the examples about updates allowed and I've read in
>> examples section:
>> "Abiword releases a new version that adds compatibility with WordStar
>> 4.0 documents. It also completely updates the user interface to use
>> pie menus. This would be a feature enhancement with a major user
>> experience change, and would not be allowed. "
>> Is that requirement honored? Because unless I miss something there is
>> a lot of updates that include only enhancements. Is not my will to
>> create a controversy but perhaps there is something in the guideliness
>> that needs (at the risk of sounding repeating) update....
> Perhaps you mean 'enforced' ?
Yup, I do, I wrote it in a hurry and my english sometimes is not so good :)
> If there is an enhancement update that adds to, but doesn't change the
> user experience, thats fine.
>> And let's say that we have a package foo-5.5 that has libfoo.so 1.0.0
>> and you make a package 6.0 with library libfoo.so 2.0.0. What should I
>> a. Submit foo 6.0 as an update
>> b. Submit foo 6.0 that coexists with foo 5.5
>> c. Submit foo 6.0 only for rawhide.
>> What is the right option?
> As with most things in life: It depends. ;)
> Very likely the answer is c.
> If there's a security bug or serious problem that is solved only in the
> new version and can't be easily backported to the existing one you
> could push it in stable releases. You should ask for an exception for
> that most likely.
> Note that if other packages depend on this library, you MUST coordinate
> with all consumers of that library to make sure they work with the new
> version and push the update at the same time, etc.
> b would be an option if there's some reason to keep the old version
> around... ie, consumers aren't updating to work with the new version
> and won't for a long time. This would also be done in rawhide unless
> there was a very good reason not to.
Thanks for your explanation, it's somewhat better that I can read at wiki :)
> devel mailing list
> devel at lists.fedoraproject.org
Sergio Belkin http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
More information about the devel