'policy' for multiple versions of same software in EPEL

[Greg Swift]

On Wed, Oct 24, 2012 at 2:08 PM, Ken Dreyer <ktdreyer at ktdreyer.com> wrote:
> On Fri, Oct 12, 2012 at 3:53 PM, Kevin Fenzi <kevin at scrye.com> wrote:
>> On Wed, 10 Oct 2012 13:13:41 -0500
>> Greg Swift <gregswift at gmail.com> wrote:
>>
>>> So... I've paid attention to the conversations around this because i
>>> was a long time zabbix user, so it affected me in that I had to build
>>> my own 'latest' packages usually or download from the maintainer's
>>> personal repository.  If I remember correctly it has also been
>>> discussed around lots of web apps like bugzilla as well.
>>
>> Yeah.
>>
>> There's a lot of apps out there that have a different release cycle
>> that RHEL has, so we have to try and adjust to that. Keeping in mind
>> that most people who are using RHEL don't like things changing very
>> much.
>
> Here's an alternative proposal I've been mentally kicking around...
>
> Red Hat itself sometimes rebases software between minor point releases
> (eg 6.0 to 6.1). Could we allow EPEL maintainers to push
> "non-backwards-compatible updates" at specific dates that match RHEL's
> minor point release schedule?
>
> As Greg points out, EPEL is essentially a rolling release today
> anyway. This would just provide a bit more structure to the rolling.
> Also, I'm hoping this would not require as much infrastructure work on
> EPEL's side.

i can get behind this concept.