'policy' for multiple versions of same software in EPEL
Kevin Fenzi
kevin at scrye.com
Mon Oct 29 18:52:01 UTC 2012
This plan has also come up before. ;)
Pros:
- Gives us a 6monthish time to retire/update things if needed.
- Gives us a clear place we can tell users: "Things might break here,
please do lots more testing, etc"
- lets us do incompatible upgrades if we need to.
Cons:
- We never know when exactly a point release is going to appear until
it does. RH never announces them in advance. So, might lead to
scrambling. It's pretty unlikely we could push those updates the same
day as the point release... so when would we? would they go through
testing as usual?
- Do we want for CentOS/SL/whatever to release their version? If not,
it could lead to breakage for users who use epel with those until
they do.
- Once we push those incompatible ones that require the new point
release, does that just leave people who are on an older one out in
the cold? Or they get the updates and it breaks them even though they
didn't apply the point release?
kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20121029/f8091177/attachment.sig>
More information about the epel-devel-list
mailing list