============================================
 EPEL Proposal #3: EPEL Structured releases
============================================

This started off as a a rawhide post, but I realized it needs to be
its own post

A staged/forked environment. This version is a lot more complicated
and deals with extra release management. Currently, Red Hat does
regular point releases (.1, .2, .3) of their main OS. In these point
releases, various items get major updates or backports to bring new
functionality to the base operating system. In this version, EPEL ties
into this staged environment by using a similar method as Fedora does.

Using a directory tree structure like:
EPEL/archives/{5.x, 6.x, 7.x}
EPEL/archives/updates/{5.x, 6.x, 7.x}
EPEL/current/5 -> 5.11/
EPEL/current/5.11/{x86_64,ppc64,x86_32}/
EPEL/current/6 -> 6.7/
EPEL/current/7 -> 7.2/
EPEL/updates/5 -> 5.11/
EPEL/updates/6 -> 6.7/
EPEL/updates/7 -> 7.2/
EPEL/updates/testing/{blah, blah}
EPEL/rawhide/{5, 6, 7}

Then packages would be built in rawhide first. When a new release (say
7.2 to 7.3) occurs, then the builders rawhide trees are updated to the
code in the latest. The packages are built against that and hopefully
tested to see that they still work. Packagers should have been
building any large changes they needed to make in the rawhide tree
already but a last minute notification date is done. The go-live for
this tree will be either when CentOS gets its build out of that tree
or 30 days if CentOS is able to release sooner. On that date the
rawhide trees will be branched to /EPEL/current/{6,7}.n (eg 7.3) and
updates to those packages will now be sent into EPEL/updates/7.3
. After another 30 days, the 7.2 tree will be moved to
EPEL/archives/7.2 {probably really /pub/archives/epel/7.2 }

Pros: this gives a place where newer packages can be built and tested
      to see what may break in the next major build. it also gives a
      better release cycle that people can plan against.

Cons: this makes the previous post look simple to implement.
-- 
Stephen J Smoogen.
_______________________________________________
epel-devel mailing list
epel-devel@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/epel-devel@lists.fedoraproject.org

Reply via email to