Release Checklist: Difference between revisions

552 bytes added ,  10 December 2019
Compare this template page with 5.0.0 Release Checklist.
m (Strip redundant Category:Development.)
(Compare this template page with 5.0.0 Release Checklist.)
Line 1: Line 1:
==GUI Release Tasks==
== 6.1 Release Tasks ==
 
This page shows the tasks to be completed before the GUI release is finalized.


<!----------------------------------------------------------------------------->
# Update gnulib to latest version
#: Must occur first as it could resolve existing, or create new, bug reports
#: Done.  You should run bootstrap in the source tree after updating to the new gnulib version.
#: Completion Date:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# File bug reports for all outstanding bugs known, but not reported
# File bug reports for all outstanding bugs known, but not reported
#* Put out a general call for reports on Octave-Maintainers and Octave-Help list
#* Put out a general call for reports on Octave-Maintainers and Octave-Help list
#: Completion Date:  
#: Completion Date:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# Review patch tracker/bug list for any patches submitted that may be included before release
# Review patch tracker/bug list for any patches submitted that may be included before release
#: Completion Date:  
#: Completion Date:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# Identify Bugs which *must* be fixed prior to release
# Identify Bugs which '''must''' be fixed prior to release
#* Review bugs on tracker for possible inclusion in list
#* Review bugs on tracker for possible inclusion in list
#* Review bugs and update to correct category, such as Patch submitted
#* Review bugs and update to correct category, such as Patch submitted
#: Completion Date:  
#: Completion Date:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# Clear all bugs identified as must-fix
# Clear all bugs identified as must-fix
#* See [[Bug Fix List]]
#* See [[6.1 Release Bug Fix List]]
#: Completion Date:
#: Completion Date:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# GPL License activities
# GPL License activities
#* Update Copyright statements for all source controlled files
#* Update Copyright statements for all source controlled files
#* Update dates in any other locations (launch message, citation, MXE files, etc.)
#* Add any new contributors to contributors.in
#* Add any new contributors to contributors.in
#: Completion Date:
#: Completion Date:
Line 27: Line 31:
# Style-check code base
# Style-check code base
#* This will produce lots of whitespace changes, but no behavior changes
#* This will produce lots of whitespace changes, but no behavior changes
#* Must occur after patches have been added since whitespace changes will often prevent patches from applying
#* Must occur after patches have been added since whitespace changes can prevent patches from applying
#: Completion Date:
#* m-file style check. Completion Date:
#* C++ style check. Completion Date:  
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# Run lint checker on code base
# Run lint checker on code base
#* cppcheck, Clang sanitize, etc.
#* Possibilities include compiling with -fsanitize=undefined and running 'make check', cppcheck, etc.  
#* PVS static analyzer results [[PVS static analyzer - 5.0 Release]]
#* Compile with -fsanitize=undefined and run 'make check'
#: Completion Date:
#: Completion Date:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# Verify 'make check' is passing
# Verify 'make check' is passing on all buildbot combinations of OS and compilers
#* Start discussion on octave-maintainers list about which failing tests must be fixed
#* Start discussion on octave-maintainers list about which failing tests must be fixed
#* Identify and fix any tests determined critical in step above
#* Identify and fix any tests determined critical in step above
#: Completion Date:
#: Completion Date:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# Run Octave test suite under [http://valgrind.org Valgrind] to check for memory leaks
# Compile and run Octave test suite with --enable-address-sanitizer-flags to check for memory leaks
#: Completion Date:
#: Completion Date:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
Line 49: Line 56:
#* Verify all formats (Info, HTML, pdf) build correctly
#* Verify all formats (Info, HTML, pdf) build correctly
#* Review NEWS for any features which should be announced
#* Review NEWS for any features which should be announced
#* Update major version number in "@subtitle Edition XXX" in octave.texi
#: Completion Date:
#: Completion Date:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# Localization and Internationalization
# Localization and Internationalization
#* Submit call for translations for GUI strings.
#* Update language translation files (*.ts)
#: Completion Date:  
#* Create issue report on Savannah as a centralized location for uploading files
#* Submit call for translations for GUI strings
#* Push translations provided by translators
#: Completion Date:
<!----------------------------------------------------------------------------->
#  Update shared library and oct file API version numbers
#* Increment oct file API version number (configure.ac:OCTAVE_API_VERSION, increment number and drop "+" suffix)
#* Increment libtool versioning (liboctave/module.mk:%canon_reldir%_%canon_reldir%_current, libinterp/module.mk:%canon_reldir%_liboctinterp_current, libgui/module.mk:%canon_reldir%_liboctgui_current)
#: Completion Date:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# Verify build process and create release candidates
# Verify build process and create release candidates
#* Update version information in configure.ac/Makefile.am
#* Update configure.ac with new version information
#**  Update AC_INIT, OCTAVE_MAJOR_VERSION, OCTAVE_MINOR_VERSION, OCTAVE_PATCH_VERSION, OCTAVE_RELEASE_DATE
#* Verify 'make distcheck' passes
#* Verify 'make distcheck' passes
#* Create release candidate
#* Create release candidate
Line 63: Line 80:
#** For Windows, create installer [[Windows Installer]]
#** For Windows, create installer [[Windows Installer]]
#** Upload release candidate
#** Upload release candidate
#** Add release candidate version to Savannah bug tracker
#** Announce release candidate to Octave-Maintainers, Octave-Help, on web page
#** Announce release candidate to Octave-Maintainers, Octave-Help, on web page
#** Repeat release candidate cycle until clean
#** Repeat release candidate cycle until clean
Line 68: Line 86:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# Final Release
# Final Release
#* hg tag repository with release
#* Update version information
#** Update configure.ac (AC_INIT, OCTAVE_MAJOR_VERSION, OCTAVE_MINOR_VERSION, OCTAVE_PATCH_VERSION, OCTAVE_RELEASE_DATE)
#** Update NEWS (final release date)
#** Update CITATION (version, year, URL)
#** Update org.octave.Octave.appdata.xml (version number and release date)
#* hg tag repository with release version number
#* merge default onto stable to become the current stable release
#* merge default onto stable to become the current stable release
#* add new release version to Savannah bug tracker
#* Savannah bug tracker version info
#* Announce final release on Octave mailing lists and web site
#** add new release version to bug tracker
#** remove release candidate versions from bug tracker
#* Announce final release on
#** Octave mailing lists
#** Octave web site
#** This wiki
#: Completion Date:
#: Completion Date:
<!----------------------------------------------------------------------------->
<!----------------------------------------------------------------------------->
# Post-Release
# Post-Release
#* Update configure.ac/Makefile.am versioning to next release cycle
#* Update configure.ac (AC_INIT, OCTAVE_MAJOR_VERSION, OCTAVE_MINOR_VERSION, OCTAVE_PATCH_VERSION) to next release cycle
#* Remove all deprecated functions scheduled for deletion in default branch
#* Update oct file API version number (configure.ac:OCTAVE_API_VERSION, add "+" suffix)
#* Remove all deprecated functions (either OCTAVE_DEPRECATED in C++ or scripts/deprecated for m-files) scheduled for deletion in default branch
#* Move NEWS file to backup in etc/NEWS.X
#* Create new NEWS file
#: Completion Date:
#: Completion Date:
==Current version policy==
According to the [http://octave.1599824.n4.nabble.com/Default-branch-merged-to-stable-td4659533.html discussions on the mailing list] ([https://lists.gnu.org/mailman/listinfo/octave-maintainers maintainers@octave.org]), a rough roadmap has been sketched for the development:
# New experimental features and development go into the '''default''' branch.
# The current Merging order goes like this: '''stable -> gui-release -> default'''
The rules for what goes on each branch are roughly
# <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 behavior 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!


[[Category:Releases]]
[[Category:Releases]]