From June 1st 2017, this release schedule is in place to generate better Core Updates. The aim is to allow developers and users to plan around this schedule and prepare for all stages.
Motivation
One of the biggest disadvantages of the IPFire 2 build system is that it is not very good with small updates and requires us to ship an entire new set of images for each change. That will waste a lot of space on the servers and of course has the entire overhead of creating the release (including changelogs, etc.).
In our normal day to day lives the world spins faster and faster with - what it feels like - less predictability. Hence we now start to bring some better predictability to the Core Updates. That will help people to book free time for development, testing and updating of their fleet of IPFire boxes.
Schedule
1. Opening of the merge window
During the 14 day merge window, developers can send patches to the development mailing list and ask for them to be merged.
Ideally this is pre-coordinated so that there is not a huge firework of emails.
Everything must be tested and peer-tested and of course complete.
2. Bug fixing phase
After everything has been merged together, additional bugs will show up that need to be fixed.
This is a task in which everyone who sent in a patch must participate. Any additional patches to fix those bugs must be sent to the list as usual. Those patches may not introduce new features. Exceptions are possible.
This phase must be completed after 14 days. Any patches or features that are causing any problems will have to be reverted or deactivated and deferred to the next release cycle.
3. Public testing
After the update has been released for public testing by the developers, the changelog will be published on the blog and everyone has the chance to test this for update.
This phase lasts about 14 days and entering it opens the merge window (step 1) and the release of the final Core Update closes the merge window.