'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