On Mon, 15 Nov 2010 17:03:49 -0500
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
I vote for b) with the below as rationale:
As a related question: for EPEL 6 can we discuss the possibility of
having EPEL6.1, EPEL6.2 releases where we consider the possibility of
releasing minor and (possibly) major package updates?
This would be a lot more infrastructure work I fear...
RHEL itself will sometimes rev minor and major versions of packages
during Y-stream releases (6.1, 6.2, etc.) I personally think that we
should consider doing something similar in EPEL. One month after each
RHEL Y-stream release, we should allow similar updates to happen in
EPEL.
Logistically, I'd be suggesting that we should maintain a primary
EPEL6 branch and an ongoing EPEL6-beta branch. Individual packages
could then be merged into the EPEL6 primary branch one month or so
after a RHEL Y-stream release.
So how would that work for the git/repo/build side?
each package would have a EL-5.1/EL-5.2/EL-5.3/EL-5.4/EL-5.5/etc
branch? If you wanted to update them all thats 6-9 builds?
It would make maintaining packages for EPEL a lot more approachable
if
there was a plan for when it would be okay to have new functionality
updates. It would also be predictable from a consumer's perspective.
So, a new minor rev would allow any new feature, but you would have to
keep the old rev on the old version? Couldn't that get confusing?
Would we need bug components then for each of the streams then I guess?
I think it could be ok, but not sure we have the infrastructure
manpower for it.
kevin