octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gui-release branch created; classdef branch merged to default and closed


From: John W. Eaton
Subject: gui-release branch created; classdef branch merged to default and closed
Date: Thu, 05 Dec 2013 12:26:01 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9

I have created the gui-release branch, merged classdef with stable, and
closed the classdef branch.

I also merged stable with gui-release and then merged gui-release with
default so everything should be up to date.  The gui-release branch
(what will become the 4.0 release with the GUI as the default
interface) should have all the changes from stable and the default
branch should have all those changes plus any that have been made on
the gui-default branch.

Repeating Jordi's rules for how things are supposed to work until
Octave 4.0 is released:

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

  * 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 default, just in case we really do need to do
    3.8.1

The rules for what goes on each branch are roughly

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


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

    WHEN IN DOUBT, ASK FOR ADVICE!

This information should probably go on a developer's info page on the
wiki.

jwe


reply via email to

[Prev in Thread] Current Thread [Next in Thread]