Release

From Open64 Wiki

Schedule

Development on our main branch will proceed in two stages.

Stage 1

During this period, changes of any nature may be made to the compiler. In particular, major changes may be merged from branches. Stage 1 is feature driven and will last at least three months. In order to avoid chaos, the Release Managers will ask for a list of major projects proposed for the coming release cycle before the start of Stage 1. They will attempt to sequence the projects in such a way as to cause minimal disruption. The Release Managers will not reject projects that will be ready for inclusion before the end of Stage 1. Similarly, the Release Managers have no special power to accept a particular patch or branch beyond what their status as maintainers affords. The role of the Release Managers during Stage 1 is merely to attempt to order the inclusion of major features in an organized manner.

Stage 2

During this two-month period, the only (non-documentation) changes that may be made are changes that fix bugs or new ports which do not require changes to other parts of the compiler. New functionality may not be introduced during this period. Rationale In order to produce releases on a regular schedule, we must ensure that the mainline is reasonably stable some time before we make the release. Therefore, more radical changes must be made earlier in the cycle, so that we have time to fix any problems that result. In order to reach higher standards of quality, we must focus on fixing bugs; by working exclusively on bug-fixing through Stage 2 and before branching for the release, we will have a higher quality source base as we prepare for a release. Although maintaining a development branch, including merging new changes from the mainline, is somewhat burdensome, the absolute worst case is that such a branch will have to be maintained for a few months. During this period, the only mainline changes will be bug-fixes, so it is unlikely that many conflicts will occur.