-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/16/2014 04:08 AM, Matthias Runge wrote: > On 01/15/2014 04:32 PM, Stephen Gallagher wrote: > >> >> So my suggestion would be that EPEL should have two branches for >> EPEL 7: the epel7 branch and the epel7-pending branch. The idea >> of this second branch would be sort of an EPEL Rawhide, where >> major upgrades can be staged. Then, when RHEL releases a minor >> update (such as RHEL 7.1), we have a (one-month?) integration >> period where we ensure that packages in epel7-pending work on the >> newest minor release and then they are merged back to epel7. If >> they miss this merge window, they have to wait until the next >> minor release. >> >> This allows us a regular, planned ability to move to newer EPEL >> packages, without destabilizing EPEL in general. >> >> In order to not make this a willy-nilly breakage every six >> months, we might want to set some limits (or at least guidelines) >> on what is or is not allowed to upgrade at the minor release. But >> I'd be fine with deferring making such decisions until we have a >> demonstrated need (i.e. fix it only if packages/EPEL is actually >> breaking). > Interesting idea, I like that. > > This would be a place to put e.g django-1.6. > > In general: when allowing package upgrades, there might be manual > steps required after package upgrade, like starting database > migrations, tweaking config files to adjust to new syntax, etc. I'm > not sure, if that is really acceptable. >
In the case of Django, my experience has been that this is often required for even minor updates (see Review Board for examples). My solution there was to work with upstream to build tools to automatically manage these upgrades so they are invisible to the package consumer. > Thoughts? > > Matthias > > _______________________________________________ epel-devel mailing > list [email protected] > https://admin.fedoraproject.org/mailman/listinfo/epel-devel > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLX6BgACgkQeiVVYja6o6PpTACdE0N5WEkjSj2JqPMOLAnwZpBg 5jYAoJGGSZdNCA72YXj7OLeaMygF9dKh =sGuM -----END PGP SIGNATURE----- _______________________________________________ epel-devel mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/epel-devel
