387
edits
Release Checklist: Difference between revisions
Jump to navigation
Jump to search
no edit summary
(Add advice about where to patch bugs) |
No edit summary |
||
| Line 2: | Line 2: | ||
# 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. | # 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. | ||
# Create a new gui-release branch based off current default | # Create a new gui-release branch based off current default | ||
# Merge classdef into default. Close classdef branch. | # Merge classdef into default. Close classdef branch. | ||
# New experimental features and development go into the default branch. This will either be a 4.2 or 5.x release. | # New experimental features and development go into the default branch. This will either be a 4.2 or 5.x release. | ||
# Merging order goes like this: stable -> gui-release -> default | # Merging order goes like this: stable -> gui-release -> default | ||
# 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. | # 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. | ||
# 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 | # 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 | ||
| Line 18: | Line 12: | ||
# <p> 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. </p> <p> 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.</p> | # <p> 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. </p> <p> 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.</p> | ||
# 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. | # 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. | ||