6.3 Release Checklist: Difference between revisions

From Octave
Jump to navigation Jump to search
Line 26: Line 26:
* Review {{Path|NEWS}} for any features which should be announced.
* Review {{Path|NEWS}} for any features which should be announced.


=== <strike> Call for translations </strike> ===
=== <strike> Translations </strike> ===
<strike>
Is this job normally done for minor releases? NO, not normally done<p>
It not, we can remove this section? YES, I used strikethrough to indicate we don't need to do anything while leaving these comments in place


* Update language translation files (*.ts). (link here when available)
<strike>We don't normally update translation files for bug-fixing releases.</strike>
* Create issue report on Savannah as a centralized location for uploading files. (link here when available)
* Call for translations for GUI strings on discourse. (link here when available)
* Collect and push all translated files
</strike>


=== <code>make check</code> ===
=== <code>make check</code> ===

Revision as of 22:46, 14 May 2021

Info icon.svg
Timeline (tentative)
Please use <strike> </strike> to mark items below as done.

Kick-off

Updates for gnulib

For bug-fixing releases, changes to gnulib should only be done to fix known serious problems. There were none for 6.3.

Bugs that should be fixed before the release

https://octave.space/savannah/?Action=get&Format=HTMLCSS&ItemID=56952,57557,59735,60209,59729,60174,60531,60471,60470

Review documentation

The following is all we should need to do for a minor release.

  • Grammar check documentation.
  • Spell check documentation.
  • Verify all formats (Info, HTML, PDF) build correctly.
  • Review NEWS for any features which should be announced.

Translations

We don't normally update translation files for bug-fixing releases.

make check

  • 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.

Create new release candidate

  • 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 discourse.

Final Release

Update version information

  • 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.
  • Update Savannah bug tracker: OPEN bugs marked as WON'T FIX should be marked as CONFIRMED (or more appropriate) for the final release.
  • Remove release candidate versions from Savannah.

Announce final release

Post-Release

  • Update version info in configure.ac on stable branch and merge with default version information.

Versioning hints

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