Release Checklist: Difference between revisions

From Octave
Jump to navigation Jump to search
(Remove two completed steps)
(Merged Roadmap and 3.8 TODO list, as it is no longer needed and might serve as template for the GUI release.)
Line 1: Line 1:
According to the discussions on the mailing list (maintainers@octave.org), a rough roadmap has been sketched for the future development.
==GUI Release Tasks==


# 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.
This page shows the tasks to be completed before the GUI release is finalized.
# 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
<!----------------------------------------------------------------------------->
# 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.
# File bug reports for all outstanding bugs known, but not reported
# 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
#* 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==
 
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
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>
# <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 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!
WHEN IN DOUBT, ASK FOR ADVICE!


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

Revision as of 23:08, 19 January 2015

GUI Release Tasks

This page shows the tasks to be completed before the GUI release is finalized.

  1. 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:
  2. Review patch tracker/bug list for any patches submitted that may be included before release
    Completion Date:
  3. 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:
  4. Clear all bugs identified as must-fix
    Completion Date:
  5. GPL License activities
    • Update Copyright statements for all source controlled files
    • Add any new contributors to contributors.in
    Completion Date:
  6. 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:
  7. Run lint checker on code base
    • cppcheck, Clang sanitize, etc.
    Completion Date:
  8. 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:
  9. Run Octave test suite under Valgrind to check for memory leaks
    Completion Date:
  10. 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:
  11. Localization and Internationalization
    • Submit call for translations for GUI strings.
    Completion Date:
  12. 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:
  13. 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:
  14. 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

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

  1. New experimental features and development go into the default branch.
  2. The current Merging order goes like this: stable -> gui-release -> default

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.

  2. 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!