On Sun, 25 Sep 2011 15:19:45 -0300 Sergio Belkin <sebelk@xxxxxxxxx> wrote: > Hi, > > I've read the examples about updates allowed and I've read in > examples section: > > http://fedoraproject.org/wiki/Updates_Policy#Examples > > "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' ? 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 > do: > > 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. kevin
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel