Although the Sabayon release process is constantly evolving, I wanted to review how we currently prepare our major releases so we can check our assumptions, and perhaps identify some areas where it needs more evolving.
This post is intended to collect feedback rather than represent a formal procedure of some kind. I apologize if I'm missing things or under-emphasizing some items. So please feel free to comment and amend this post. Some aspects of the Sabayon release process are highly structured, such as the automated process for producing the DAILYs. However, we avoid imposing too much structure on the manual aspects of the release process so we can retain the flexibility to adjust the process as needed without the inertia of having to officially change a procedure. Our primary (Tier 1) release consists of 8 versions: Gnome, KDE, XFCE, and CoreCDX in x86 and x86_64. We also release a SpinBase and ServerBase edition. (1) DAILYS The process for building the DAILY releases is the foundation of our release process. Over time, we have automated most of the tasks involved in assembling a release. Although the build server produces DAILY releases every day, we only release them to the public twice a week. We found that releasing them daily was actually less convenient for testing, and would sometimes confuse issues. (2) ARTWORK Each release gets a fresh coat of paint. A significant element of artwork includes theming. And theming relies on freezing (or at least partially freezing) the major desktop elements such as Gnome, KDE and XFCE. (3) FREEZE With each release, we have a period of time where we 'freeze' updating of entropy with new packages. This gives us a period of time to make sure everything in the release is working correctly together. If new packages are constantly being injected into the release, it is nearly impossible to settling things down enough to get a stable release. We try to minimize the 'freeze' period since it results in a backlog of accumulated updates as soon as we publish the release. Immediately prior to the 'freeze' period, we usually have a period of high activity updating Entropy to get ready for the release. While the concept of a 'freeze' period is very simple, in practice the transition into the 'freeze' period can be somewhat unstructured. There are usually several exceptions that must be manually handled in each freeze period. (4) TESTING The testing phase of our release process is loosely structured. We've had a difficult time establishing a formal testing program that reconciles the broad spectrum of things that could be tested with the availability of developers and testers. The DAILYs are always available for testing, and we have the assumption that a certain number of users are picking up our DAILYs and using them. We like for the heaviest testing to occur after we start the 'freeze' period, but before we enter the final phase of preparing the release. (5) FINISHING Once we get to the point where we THINK we have a final release, it still requires several days to do our final assembly and testing before we can push the release to the mirrors, and make our release announcement.
