Default branch merged to stable

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Default branch merged to stable

Rik-4
11/25/13

All of the good work on the development branch has been transferred to the
stable branch.  If you have changesets for the 3.8 release they should now
be applied to the stable branch.  The default branch is now for development
on the 4.0 release.

--Rik
Reply | Threaded
Open this post in threaded view
|

What's appropriate for the default branch? (was: Re: Default branch merged to stable)

John W. Eaton
Administrator
On 11/26/2013 01:20 AM, Rik wrote:

> If you have changesets for the 3.8 release they should now
> be applied to the stable branch.  The default branch is now for development
> on the 4.0 release.

What's appropriate for the default branch now?

If our focus for 4.0 is a solid GUI, then I think we should focus on
that alone and leave other changes until later.  But that means that
we don't really have a good place for people to push changes for new
features that are not focused on the GUI or classdef.

I also don't think that we should be doing all the work for 4.0 on the
stable branch.  We may have to break binary compatibility when making
some of the 4.0 changes and it may take more than a few months for 4.0
to be ready.  But we should try to ensure that we are able to release
3.8.N at any time without breaking binary compatibility with previous
3.8 releases.

Would it make sense to create an intermediate branch that is intended
for the work on the 4.0 release?  Then we could leave default open for
any other kinds of possibly risky changes.  If we go this route, I
would merge classdef to default.

Then we would have:

   stable:  3.8.x series

   gui:     Future 4.0.x series with stable GUI.  Most work focuses on
            this branch until 4.0 is released.

   default: The usual (almost) anything goes branch.  Merge classdef
            here and close the classdef branch.  The big new feature
            for a future 4.x release (or maybe 5.0) would be classdef
            support.

But I would also like to propose that we try to have a better plan for
default than we have had in the past and avoid a truly "anything goes"
approach because that's the kind of thing that results in new stable
releases not happening for two or more years.

Comments?

jwe
Reply | Threaded
Open this post in threaded view
|

Re: What's appropriate for the default branch?

Torsten
On 28.11.2013 19:13, John W. Eaton wrote:

> On 11/26/2013 01:20 AM, Rik wrote:
>
>> If you have changesets for the 3.8 release they should now
>> be applied to the stable branch.  The default branch is now for
>> development
>> on the 4.0 release.
>
> What's appropriate for the default branch now?
>
> If our focus for 4.0 is a solid GUI, then I think we should focus on
> that alone and leave other changes until later.  But that means that
> we don't really have a good place for people to push changes for new
> features that are not focused on the GUI or classdef.
>
> I also don't think that we should be doing all the work for 4.0 on the
> stable branch.  We may have to break binary compatibility when making
> some of the 4.0 changes and it may take more than a few months for 4.0
> to be ready.  But we should try to ensure that we are able to release
> 3.8.N at any time without breaking binary compatibility with previous
> 3.8 releases.
>
> Would it make sense to create an intermediate branch that is intended
> for the work on the 4.0 release?  Then we could leave default open for
> any other kinds of possibly risky changes.  If we go this route, I
> would merge classdef to default.
>
> Then we would have:
>
>   stable:  3.8.x series
>
>   gui:     Future 4.0.x series with stable GUI.  Most work focuses on
>            this branch until 4.0 is released.
>
>   default: The usual (almost) anything goes branch.  Merge classdef
>            here and close the classdef branch.  The big new feature
>            for a future 4.x release (or maybe 5.0) would be classdef
>            support.

Does this mean that improvements or bug fixes for the gui are not
included in future 3.8.x releases?

Torsten
Reply | Threaded
Open this post in threaded view
|

Re: What's appropriate for the default branch?

Rik-4
In reply to this post by John W. Eaton
On 11/28/2013 10:13 AM, John W. Eaton wrote:

> On 11/26/2013 01:20 AM, Rik wrote:
>
>> If you have changesets for the 3.8 release they should now
>> be applied to the stable branch.  The default branch is now for development
>> on the 4.0 release.
>
> What's appropriate for the default branch now?
>
> If our focus for 4.0 is a solid GUI, then I think we should focus on
> that alone and leave other changes until later.  But that means that
> we don't really have a good place for people to push changes for new
> features that are not focused on the GUI or classdef.
>
> I also don't think that we should be doing all the work for 4.0 on the
> stable branch.  We may have to break binary compatibility when making
> some of the 4.0 changes and it may take more than a few months for 4.0
> to be ready.  But we should try to ensure that we are able to release
> 3.8.N at any time without breaking binary compatibility with previous
> 3.8 releases.
>
> Would it make sense to create an intermediate branch that is intended
> for the work on the 4.0 release?  Then we could leave default open for
> any other kinds of possibly risky changes.  If we go this route, I
> would merge classdef to default.
>
> Then we would have:
>
>   stable:  3.8.x series
>
>   gui:     Future 4.0.x series with stable GUI.  Most work focuses on
>            this branch until 4.0 is released.
>
>   default: The usual (almost) anything goes branch.  Merge classdef
>            here and close the classdef branch.  The big new feature
>            for a future 4.x release (or maybe 5.0) would be classdef
>            support.
>
> But I would also like to propose that we try to have a better plan for
> default than we have had in the past and avoid a truly "anything goes"
> approach because that's the kind of thing that results in new stable
> releases not happening for two or more years.
>
> Comments?
>
I agree that the stable branch should remain slow-to-change and no
significant development work (GUI or otherwise) should take place there.
As for the the other, I like the simplicity of ping/ponging between a
stable and a development branch and would be just as happy without a third
GUI branch.  In my experience the default branch has not been wildly
experimental.  Except for a few days spread over the years, one could
always just do an 'hg pull; bootstrap; config; make' cycle and have it
work.  I could see isolating the GUI work if we thought that other changes
were going to de-stabilize the source tree to such a degree that it might
not be releasable in 6 months, but that hasn't been the past history of the
archive.  Now maybe the changes on the classdef branch do represent such a
change, but if they are more than 6 months from finalization then maybe
they should just continue to live on their own separate named branch rather
than hijacking the default branch.  Those are my thoughts, but either way
will be fine for me.

--Rik
Reply | Threaded
Open this post in threaded view
|

Re: What's appropriate for the default branch?

John W. Eaton
Administrator
On 11/29/2013 07:11 PM, Rik wrote:

> I agree that the stable branch should remain slow-to-change and no
> significant development work (GUI or otherwise) should take place there.
> As for the the other, I like the simplicity of ping/ponging between a
> stable and a development branch and would be just as happy without a third
> GUI branch.  In my experience the default branch has not been wildly
> experimental.  Except for a few days spread over the years, one could
> always just do an 'hg pull; bootstrap; config; make' cycle and have it
> work.  I could see isolating the GUI work if we thought that other changes
> were going to de-stabilize the source tree to such a degree that it might
> not be releasable in 6 months, but that hasn't been the past history of the
> archive.

My impression is that we are rarely ready for release.  When we
announce that we are about to release, everyone suddenly shows up with
a bunch of "must fix" bug reports and it takes us months to actually
make a release.

I'm not sure what the solution to this problem is.  More frequent
regular releases regardless of whether some big new feature like the
GUI or classdef is really finished?  Maintaining a
"we-could-release-from-this-at-any-time" branch that is not open for
changes unless tehy are truly finished and well tested?

I'm not thrilled about having a lot of branches, but in this
particular case I think it makes sense to have the separate branch for
the 4.0 with the GUI for real release.  I would just do that work on
stable but I'm thinking that it will take long enough to get 4.0 ready
that we may need to make another 3.8.x release.

> Now maybe the changes on the classdef branch do represent such a
> change, but if they are more than 6 months from finalization then maybe
> they should just continue to live on their own separate named branch rather
> than hijacking the default branch.

If we do that, then I think classdef doesn't get much testing.

jwe
Reply | Threaded
Open this post in threaded view
|

Re: What's appropriate for the default branch?

Rik-4
On 11/29/2013 05:29 PM, John W. Eaton wrote:

> On 11/29/2013 07:11 PM, Rik wrote:
>
>> I agree that the stable branch should remain slow-to-change and no
>> significant development work (GUI or otherwise) should take place there.
>> As for the the other, I like the simplicity of ping/ponging between a
>> stable and a development branch and would be just as happy without a third
>> GUI branch.  In my experience the default branch has not been wildly
>> experimental.  Except for a few days spread over the years, one could
>> always just do an 'hg pull; bootstrap; config; make' cycle and have it
>> work.  I could see isolating the GUI work if we thought that other changes
>> were going to de-stabilize the source tree to such a degree that it might
>> not be releasable in 6 months, but that hasn't been the past history of the
>> archive.
>
> My impression is that we are rarely ready for release.  When we
> announce that we are about to release, everyone suddenly shows up with
> a bunch of "must fix" bug reports and it takes us months to actually
> make a release.
I think a lot of the "must fix" bugs were related to the GUI.  If we had
simply acknowledged in our heart of hearts that the GUI wasn't ready for
this release cycle we could have moved on and produced 3.8 in a relatively
short time.  So, I'll still maintain that I usually find the development
branch close to release-worthy.
>
> I'm not sure what the solution to this problem is.  More frequent
> regular releases regardless of whether some big new feature like the
> GUI or classdef is really finished?
This is very modern, a la Chrome, but I dislike it.  Why waste people's
time downloading something that provides an infinitesimal improvement?
When we have something good that people would benefit from, then we should
release it, but not simply because 42 days have passed.
>   Maintaining a
> "we-could-release-from-this-at-any-time" branch that is not open for
> changes unless tehy are truly finished and well tested?
We could try it.  It will be complicated, however, to remember which
changesets have been cherrypicked into the release branch and which have
not when we do a substantial release.  Mercurial might have ways of
alleviating that though.
>
> I'm not thrilled about having a lot of branches, but in this
> particular case I think it makes sense to have the separate branch for
> the 4.0 with the GUI for real release.  I would just do that work on
> stable but I'm thinking that it will take long enough to get 4.0 ready
> that we may need to make another 3.8.x release.
I think that working on stable is bad, so I will be fine with any plan that
avoids that.
>
>> Now maybe the changes on the classdef branch do represent such a
>> change, but if they are more than 6 months from finalization then maybe
>> they should just continue to live on their own separate named branch rather
>> than hijacking the default branch.
>
> If we do that, then I think classdef doesn't get much testing.
This is a classic chicken and egg problem.  You don't want to even bring
the classdef branch on to default unless it has a minimum level of
functionality and robustness, but the robustness can't be tested until it
is brought into wider usage.  Is classdef support in Octave going to occur
in the 4.X series or 5.X series?  If it is a goal for release 4.4 or 4.6 I
would still say it is too early to bring it on to default.

These are only my opinions.  I really will be fine with whatever strategy
we take.  Also, I'm not much of a GUI programmer so I will still end up
spending my time either on the stable or default branches.

--Rik
Reply | Threaded
Open this post in threaded view
|

3.8 -> 4.0 transition plans

Jordi Gutiérrez Hermoso-2
I think the following proposal makes sense:

   1) 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.

   2) Create a new gui-release branch based off current default

   3) Merge classdef into default. Close classdef branch.

   4) New experimental features and development go into the default
      branch. This will either be a 4.2 or 5.x release.

   5) Merging order goes like this: stable -> gui-release -> default

   6) 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.

   7) 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

So, basically, replace the classdef branch by putting it into default
and adding an intermediate gui-release branch between stable and
default.

Sounds good?

- Jordi G. H.



Reply | Threaded
Open this post in threaded view
|

Re: 3.8 -> 4.0 transition plans

John W. Eaton
Administrator
On 12/02/2013 05:02 PM, Jordi Gutiérrez Hermoso wrote:

> I think the following proposal makes sense:
>
>     1) 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.
>
>     2) Create a new gui-release branch based off current default
>
>     3) Merge classdef into default. Close classdef branch.
>
>     4) New experimental features and development go into the default
>        branch. This will either be a 4.2 or 5.x release.
>
>     5) Merging order goes like this: stable -> gui-release -> default
>
>     6) 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.
>
>     7) 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
>
> So, basically, replace the classdef branch by putting it into default
> and adding an intermediate gui-release branch between stable and
> default.
>
> Sounds good?

Yes.  That's more detailed that what I proposed earlier, but I think
it's the same general idea.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: 3.8 -> 4.0 transition plans

Mike Miller
On Mon, 2 Dec 2013 18:55:46 -0500, John W. Eaton wrote:

> On 12/02/2013 05:02 PM, Jordi Gutiérrez Hermoso wrote:
>> I think the following proposal makes sense:
>>
>>     1) 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.
>>
>>     2) Create a new gui-release branch based off current default
>>
>>     3) Merge classdef into default. Close classdef branch.
>>
>>     4) New experimental features and development go into the default
>>        branch. This will either be a 4.2 or 5.x release.
>>
>>     5) Merging order goes like this: stable -> gui-release -> default
>>
>>     6) 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.
>>
>>     7) 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
>>
>> So, basically, replace the classdef branch by putting it into default
>> and adding an intermediate gui-release branch between stable and
>> default.
>>
>> Sounds good?
>
> Yes.  That's more detailed that what I proposed earlier, but I think
> it's the same general idea.

This plan looks good to me too. I had planned on replying to the earlier
plan in this thread that it was confusing and I would not know which
branch certain fixes should go on. This clears things up quite a lot.

The key points that made this more practical to me are the time frames
and merge plans. This basically allows the GUI work to stay in "release
mode" for a not-too-far-in-the-future 4.0 release while development on
default works as before for the next release beyond that.

There is still ambiguity about where non-GUI bug fixes should go. In the
last release cycle, mostly documentation and regression bug fixes went
on the stable branch for the next point release. In this plan, some
measure of criticality will determine whether a non-GUI bug fix should
go on stable, gui-release, or default.

If we stick to the plan of having a 4.0 improved GUI release very soon,
less than 6 months, then it's ok to put non-regression bug fixes on the
default branch as before, and say that the fix will be released in 4.2.
If the schedule slips, then we end up having a 4.0 release with a new
GUI but a whole backlog of fixed bugs that won't be released for another
year or so. These are my main concerns about this plan, any thoughts?

--
mike
Reply | Threaded
Open this post in threaded view
|

Re: 3.8 -> 4.0 transition plans

Jordi Gutiérrez Hermoso-2
On Tue, 2013-12-03 at 10:05 -0500, Mike Miller wrote:

> There is still ambiguity about where non-GUI bug fixes should go. In
> the last release cycle, mostly documentation and regression bug
> fixes went on the stable branch for the next point release. In this
> plan, some measure of criticality will determine whether a non-GUI
> bug fix should go on stable, gui-release, or default.

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.

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.

- Jordi G. H.



Reply | Threaded
Open this post in threaded view
|

Re: 3.8 -> 4.0 transition plans

John W. Eaton
Administrator
On 12/03/2013 01:34 PM, Jordi Gutiérrez Hermoso wrote:

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

Also, 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 I think that 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.

jwe

Reply | Threaded
Open this post in threaded view
|

Re: 3.8 -> 4.0 transition plans

rezahousseini



On Tue, Dec 3, 2013 at 7:53 PM, John W. Eaton <[hidden email]> wrote:
On 12/03/2013 01:34 PM, Jordi Gutiérrez Hermoso wrote:

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.

Also, 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 I think that 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.

jwe


I just created a new Wiki page [1]. Could we collect the findings of this conversations here?

Reply | Threaded
Open this post in threaded view
|

Re: 3.8 -> 4.0 transition plans

Michael Godfrey
In reply to this post by Jordi Gutiérrez Hermoso-2
On 12/02/2013 10:02 PM, Jordi Gutiérrez Hermoso wrote:
> So, basically, replace the classdef branch by putting it into default
> and adding an intermediate gui-release branch between stable and
> default.
>
> Sounds good?
>
> - Jordi G. H.
Sounds good to me. It looks like the classdef branch could be merged soon,
and the gui-release fairly soon after.  The sooner a return to stable
and default
the better.  This "transition" time has gone better than I had feared,
but this
should not be an argument for trying it again.

Anyhow, a lot of good work has gotten done and the sooner users get
to benefit from it the better.

Michael
Reply | Threaded
Open this post in threaded view
|

Fwd: 3.8 -> 4.0 transition plans

Pascal Dupuis-3
2014-03-13 21:30 GMT+01:00 Michael D. Godfrey <[hidden email]>:

> Sounds good to me. It looks like the classdef branch could be merged soon,
> and the gui-release fairly soon after.  The sooner a return to stable and
> default
> the better.  This "transition" time has gone better than I had feared, but
> this
> should not be an argument for trying it again.
>
> Anyhow, a lot of good work has gotten done and the sooner users get
> to benefit from it the better.
>

Hello,

I found a few ... oddities in the way Java is detected under cygwin64.
I'm fixing them now; basically it boils down to strange interaction
betweens Unix and MSYS conventions about path separator.  I would like
to have those changes integrated and tested before the next big
release.

Regards

Pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: 3.8 -> 4.0 transition plans

marco atzeri-2


On 14/03/2014 11:58, Pascal Dupuis wrote:

> 2014-03-13 21:30 GMT+01:00 Michael D. Godfrey <[hidden email]>:
>
>> Sounds good to me. It looks like the classdef branch could be merged soon,
>> and the gui-release fairly soon after.  The sooner a return to stable and
>> default
>> the better.  This "transition" time has gone better than I had feared, but
>> this
>> should not be an argument for trying it again.
>>
>> Anyhow, a lot of good work has gotten done and the sooner users get
>> to benefit from it the better.
>>
>
> Hello,
>
> I found a few ... oddities in the way Java is detected under cygwin64.
> I'm fixing them now; basically it boils down to strange interaction
> betweens Unix and MSYS conventions about path separator.  I would like
> to have those changes integrated and tested before the next big
> release.
>
> Regards
>
> Pascal

Pascal,
cygwin has no java package/programs.

As such, interaction from other windows version of java is NOT supposed
to work.
Please skip detection defining a restricted PATH with only cygwin binaries.

Regards
Marco



Reply | Threaded
Open this post in threaded view
|

Re: Fwd: 3.8 -> 4.0 transition plans

Pascal Dupuis-3
2014-03-14 14:45 GMT+01:00 Marco Atzeri <[hidden email]>:

>
> Pascal,
> cygwin has no java package/programs.
>
> As such, interaction from other windows version of java is NOT supposed to
> work.
> Please skip detection defining a restricted PATH with only cygwin binaries.
>

Hello Marco,

I know :-) I'm trying to interface directly to the Windows version of
JRE/JDK. Withouyt trying we can not tell weither or not this works.

Regards

Pascal
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: 3.8 -> 4.0 transition plans

marco atzeri-2

On 14/03/2014 15:22, Pascal Dupuis wrote:

> 2014-03-14 14:45 GMT+01:00 Marco Atzeri <[hidden email]>:
>
>>
>> Pascal,
>> cygwin has no java package/programs.
>>
>> As such, interaction from other windows version of java is NOT supposed to
>> work.
>> Please skip detection defining a restricted PATH with only cygwin binaries.
>>
>
> Hello Marco,
>
> I know :-) I'm trying to interface directly to the Windows version of
> JRE/JDK. Withouyt trying we can not tell weither or not this works.
>
> Regards
>
> Pascal

Sorry Pascal,
it will not work.
Cygwin and Widows Java have not compatible expectation/behaviour.

If you need Java, you need to use the Mingw or MSVC build.

Regards
Marco