Difference between revisions of "Release Checklist"

From Octave
Jump to navigation Jump to search
m (Strip redundant Category:Development.)
 
(22 intermediate revisions by the same user not shown)
Line 1: Line 1:
==GUI Release Tasks==
+
Please use
  
This page shows the tasks to be completed before the GUI release is finalized.
+
<strike></strike>
  
<!----------------------------------------------------------------------------->
+
to mark items as done.
# 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
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Review patch tracker/bug list for any patches submitted that may be included before release
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Identify Bugs which *must* be fixed prior to release
 
#* Review bugs on tracker for possible inclusion in list
 
#* Review bugs and update to correct category, such as Patch submitted
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Clear all bugs identified as must-fix
 
#* See [[Bug Fix List]]
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# GPL License activities
 
#* Update Copyright statements for all source controlled files
 
#* Add any new contributors to contributors.in
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Style-check code base
 
#* 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
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Run lint checker on code base
 
#* cppcheck, Clang sanitize, etc.
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Verify 'make check' is passing
 
#* Start discussion on octave-maintainers list about which failing tests must be fixed
 
#* Identify and fix any tests determined critical in step above
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Run Octave test suite under [http://valgrind.org Valgrind] to check for memory leaks
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Review documentation
 
#* Grammar check documentation so that it conforms to Octave standards
 
#* Spell check documentation
 
#* Verify no functions missing from manual
 
#* Verify deprecated functions removed from "see also" links
 
#* Verify all formats (Info, HTML, pdf) build correctly
 
#* Review NEWS for any features which should be announced
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Localization and Internationalization
 
#* Submit call for translations for GUI strings.
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Verify build process and create release candidates
 
#* Update version information in configure.ac/Makefile.am
 
#* Verify 'make distcheck' passes
 
#* Create release candidate
 
#** 'make dist'
 
#** hg tag repository with release candidate ID
 
#** For Windows, create installer [[Windows Installer]]
 
#** Upload release candidate
 
#** Announce release candidate to Octave-Maintainers, Octave-Help, on web page
 
#** Repeat release candidate cycle until clean
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Final Release
 
#* hg tag repository with release
 
#* merge default onto stable to become the current stable release
 
#* add new release version to Savannah bug tracker
 
#* Announce final release on Octave mailing lists and web site
 
#: Completion Date:
 
<!----------------------------------------------------------------------------->
 
# Post-Release
 
#* Update configure.ac/Makefile.am versioning to next release cycle
 
#* Remove all deprecated functions scheduled for deletion in default branch
 
#: Completion Date:
 
  
==Current version policy==
+
== Kickoff ==
  
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:
+
=== Update gnulib to latest version ===
 +
:Completion Date:
 +
:Must occur first as it could resolve existing, or create new, bug reports. You should run <code>./bootstrap</code> in the source tree after updating to the new gnulib version.
  
# New experimental features and development go into the '''default''' branch.
+
=== Call for bug reports ===
# The current Merging order goes like this: '''stable -> gui-release -> default'''
+
:Completion Date:
 +
* Put out a general call for reports on maintainers@octave.org and help@octave.org for all outstanding unreported known bugs.
  
The rules for what goes on each branch are roughly
+
=== Review submitted patches on Savannah ===
 +
:Completion Date:
 +
* Submitted patches from '''bug tracker''' included.
 +
* Submitted patches from '''patch tracker''' included.
  
# <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>
+
=== Review open bugs on Savannah ===
# 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.
+
:Completion Date:
 +
* Review bugs and update to correct category, such as "Patch submitted", correct title if necessary.
 +
* Add "must-fix" items to [[6.1 Release Bug Fix List]].
  
WHEN IN DOUBT, ASK FOR ADVICE!
+
== One time tasks ==
 +
 
 +
=== GPL License activities ===
 +
:Completion Date:
 +
* 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 {{Path|doc/interpreter/contributors.in}} who wish to be mentioned (don't add them without permission).
 +
 
 +
=== Style-check code base ===
 +
:Completion Date:
 +
: This will produce lots of whitespace changes, but no behavior changes. '''Must occur after patches have been added''', since whitespace changes can prevent patches from applying.
 +
* m-file style check
 +
* C++ style check
 +
 
 +
=== Review documentation ===
 +
:Completion Date:
 +
* Grammar check documentation.
 +
* Spell check documentation.
 +
* Verify no functions missing from manual.
 +
* Verify deprecated functions removed from "see also" links.
 +
* Verify all formats (Info, HTML, PDF) build correctly.
 +
* Review {{Path|NEWS}} for any features which should be announced.
 +
* Update major version number in "@subtitle Edition XXX" in {{Path|octave.texi}}.
 +
 
 +
=== Call for translations ===
 +
:Completion Date:
 +
* Update language translation files (*.ts).
 +
* Create issue report on Savannah as a centralized location for uploading files.
 +
* Call for translations for GUI strings on maintainers@octave.org.
 +
 
 +
== Repeat until all bugs are resolved ==
 +
:Completion Date first iteration:
 +
 
 +
=== Merge submitted patches ===
 +
* Push translations provided by translators.
 +
* Push reviewed patches from Savannah.
 +
 
 +
=== <code>make check</code> ===
 +
* Verify <code>make check</code> is passing on all [http://buildbot.octave.org:8010/#/waterfall buildbot combinations of OS and compilers].
 +
* Compiling with <code>-fsanitize=undefined</code>, <code>--enable-address-sanitizer-flags</code> to check for memory leaks. Use other tools <code>cppcheck</code>, etc.
 +
** Update PVS static analyzer results [[PVS static analyzer - 5.0 Release]].
 +
* Start discussion on maintainers@octave.org about which failing tests that must be fixed and which can be declared '''WON'T FIX'''.
 +
 
 +
=== Create new release candidate ===
 +
* Ensure correct [[#Versioning hints|version information]].
 +
* Create hg tag in repository with release candidate version number.
 +
* Verify <code>make distcheck</code> passes.
 +
* Verify <code>make dist</code> works.
 +
* Create [[Windows Installer]].
 +
* Upload release candidates.
 +
* Add release candidate version to Savannah bug tracker.
 +
* Announce release candidate to maintainers@octave.org, help@octave.org mailing-list, on web page.
 +
 
 +
== Final Release ==
 +
 
 +
=== Update version information ===
 +
:Completion Date:
 +
* Ensure correct [[#Versioning hints|version information]].
 +
* Create hg tag in repository with release version number.
 +
* Update {{Path|NEWS}} (final release date).
 +
* Update {{Path|CITATION}} (version, year, URL).
 +
* Update {{Path|org.octave.Octave.appdata.xml}} (version number and release date).
 +
* Update Savannah bug tracker version info.
 +
* Remove release candidate versions from Savannah.
 +
 
 +
=== Announce final release ===
 +
:Completion Date:
 +
* Octave mailing-lists
 +
* Octave web site
 +
* This wiki
 +
 
 +
== Post-Release ==
 +
:Completion Date:
 +
* Merge default onto stable to become the current stable release.
 +
* Ensure correct [[#Versioning hints|version information]].
 +
* Remove all deprecated functions (either <code>OCTAVE_DEPRECATED</code> in C++ or scripts/deprecated for m-files) scheduled for deletion in "default" branch.
 +
* Move {{Path|NEWS}} file to backup in {{Path|etc/NEWS.X}}.
 +
* Create new {{Path|NEWS}} file.
 +
 
 +
== Versioning hints ==
 +
 
 +
{{Note|Read [https://hg.savannah.gnu.org/hgweb/octave/file/tip/etc/HACKING.md <code>etc/HACKING.md</code>] carefully!!}}
 +
 
 +
* Update {{Path|configure.ac}}:
 +
** <code>AC_INIT</code>
 +
** <code>OCTAVE_API_VERSION</code>
 +
** <code>OCTAVE_MAJOR/MINOR/PATCH_VERSION</code>
 +
** <code>OCTAVE_RELEASE_DATE</code>
 +
* Update libtool versioning:
 +
** {{Path|liboctave/module.mk}} <code>%canon_reldir%_%canon_reldir%_current</code>
 +
** {{Path|libinterp/module.mk}} <code>%canon_reldir%_liboctinterp_current</code>
 +
** {{Path|libgui/module.mk}} <code>%canon_reldir%_liboctgui_current</code>
  
 
[[Category:Releases]]
 
[[Category:Releases]]

Latest revision as of 01:49, 10 December 2019

Please use

<strike></strike>

to mark items as done.

Kickoff[edit]

Update gnulib to latest version[edit]

Completion Date:
Must occur first as it could resolve existing, or create new, bug reports. You should run ./bootstrap in the source tree after updating to the new gnulib version.

Call for bug reports[edit]

Completion Date:
  • Put out a general call for reports on maintainers@octave.org and help@octave.org for all outstanding unreported known bugs.

Review submitted patches on Savannah[edit]

Completion Date:
  • Submitted patches from bug tracker included.
  • Submitted patches from patch tracker included.

Review open bugs on Savannah[edit]

Completion Date:
  • Review bugs and update to correct category, such as "Patch submitted", correct title if necessary.
  • Add "must-fix" items to 6.1 Release Bug Fix List.

One time tasks[edit]

GPL License activities[edit]

Completion Date:
  • 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 doc/interpreter/contributors.in who wish to be mentioned (don't add them without permission).

Style-check code base[edit]

Completion Date:
This will produce lots of whitespace changes, but no behavior changes. Must occur after patches have been added, since whitespace changes can prevent patches from applying.
  • m-file style check
  • C++ style check

Review documentation[edit]

Completion Date:
  • Grammar check documentation.
  • Spell check documentation.
  • Verify no functions missing from manual.
  • Verify deprecated functions removed from "see also" links.
  • Verify all formats (Info, HTML, PDF) build correctly.
  • Review NEWS for any features which should be announced.
  • Update major version number in "@subtitle Edition XXX" in octave.texi.

Call for translations[edit]

Completion Date:
  • Update language translation files (*.ts).
  • Create issue report on Savannah as a centralized location for uploading files.
  • Call for translations for GUI strings on maintainers@octave.org.

Repeat until all bugs are resolved[edit]

Completion Date first iteration:

Merge submitted patches[edit]

  • Push translations provided by translators.
  • Push reviewed patches from Savannah.

make check[edit]

  • Verify make check is passing on all buildbot combinations of OS and compilers.
  • Compiling with -fsanitize=undefined, --enable-address-sanitizer-flags to check for memory leaks. Use other tools cppcheck, etc.
  • Start discussion on maintainers@octave.org about which failing tests that must be fixed and which can be declared WON'T FIX.

Create new release candidate[edit]

  • Ensure correct version information.
  • Create hg tag in repository with release candidate version number.
  • Verify make distcheck passes.
  • Verify make dist works.
  • Create Windows Installer.
  • Upload release candidates.
  • Add release candidate version to Savannah bug tracker.
  • Announce release candidate to maintainers@octave.org, help@octave.org mailing-list, on web page.

Final Release[edit]

Update version information[edit]

Completion Date:
  • Ensure correct version information.
  • Create hg tag in repository with release version number.
  • Update NEWS (final release date).
  • Update CITATION (version, year, URL).
  • Update org.octave.Octave.appdata.xml (version number and release date).
  • Update Savannah bug tracker version info.
  • Remove release candidate versions from Savannah.

Announce final release[edit]

Completion Date:
  • Octave mailing-lists
  • Octave web site
  • This wiki

Post-Release[edit]

Completion Date:
  • Merge default onto stable to become the current stable release.
  • Ensure correct version information.
  • 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.

Versioning hints[edit]

Info icon.svg
Read etc/HACKING.md carefully!!
  • Update configure.ac:
    • AC_INIT
    • OCTAVE_API_VERSION
    • OCTAVE_MAJOR/MINOR/PATCH_VERSION
    • OCTAVE_RELEASE_DATE
  • Update libtool versioning:
    • liboctave/module.mk %canon_reldir%_%canon_reldir%_current
    • libinterp/module.mk %canon_reldir%_liboctinterp_current
    • libgui/module.mk %canon_reldir%_liboctgui_current