Release Checklist

According to the discussions on the mailing list (maintainers@octave.org), a rough roadmap has been sketched for the future development.

1. Work for the next few days on the stable branch until a release is ready, in whatever state it is in within the next few days. The outstanding big bugs are in the GUI, and we've agreed that we'll just release with those bugs and the warnings that jwe has put in.

1. Create a new gui-release branch based off current default

1. Merge classdef into default. Close classdef branch.

1. New experimental features and development go into the default branch. This will either be a 4.2 or 5.x release.

1. Merging order goes like this: stable -> gui-release -> default

1. After the 3.8 release, we work hard on the gui-release branch and release 4.0 from gui-release. Final merge of gui-release into default and close gui-release. Hopefully we can do this within a few months, say, no more than 4.

1. Try to focus all efforts on gui-release to the extent that a 3.8.1 release won't even be necessary, but as usual, critical bugs in the 3.8 release get patched on stable and forward-merged into release-gui and fault, just in case we really do need to do 3.8.1

The rules for what goes on each branch are roughly

1. Critical non-GUI fixes found in the stable release go on stable and get forward-merged into release-gui and default. We know the GUI is full of bugs, which is the point of the release-gui branch, so all GUI fixes go into gui-release. Fixes that break API go into default.

   But note that since we are not installing any of the headers from the libgui directory, there are few (if any) changes that we could make to the GUI that could considered to break the API. So pretty much any change to the GUI is allowed as long as it only touches files in the libgui directory. But of course we are expecting that changes to the GUI improve stability and remove bugs, not the opposite, so let's not go too wild with redesigning and refactoring. We can think about those things after 4.0.

1. Everything else is shades of grey, but I recommend for starters: fixes that change non-GUI behaviour or API go into default. Simple fixes can go into gui-release, more complex changes into default. The shades of grey are deciding what "simple" and "complex" mean, but we can judge these on a case-by-case basis.

WHEN IN DOUBT, ASK FOR ADVICE!