Release Ideas

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

Re: Keeping the gui-release branch open considered harmful

Mike Miller
On Fri, Jan 30, 2015 at 09:15:27 -0800, Rik wrote:
> But the original comment still stands.  If someone is willing to merge the
> two branches and everyone feels that classdef and the new audio system are
> ready for release then I won't stand in the way.

I think I'm with Rik here. I was and am in favor of keeping the branches
and release plans we had made last year, but I'm not aware of the size
of the accumulated delta between the two branches and the difficulty
that might bring with fixing things on gui-release and having to
significantly rework them to merge them on the default branch.

I still think a more stable 4.0 GUI release with much improved Windows
support would be better. Even if it doesn't bring any of a number of
fixes that have been made on default. How many more large changes would
need to be made on gui-release before a 4.0 release that would need to
be refactored to be merged onto default?

I don't deal with merging the mercurial branches at all, so I have no
concept of how much work it's been to maintain this model.

So all that said, if it is too large of a burden to make significantly
different fixes on the two branches, I'm ok with closing gui-release and
making default be the 4.0 release.

I made a similar comment to jwe on irc the other day about classdef. I'm
wary about making it part of the next release, since it affects the
parser, but as long as it doesn't introduce any problematic regressions
it should be fine to have it as a new feature for users to experiment
with and test for us.

Since we're talking release soon-ish either way, I've started looking
through the bug tracker to identify crashes and bugs that look like they
might be blockers.

--
mike

Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

John W. Eaton
Administrator
In reply to this post by Daniel Sebald
On 01/30/2015 12:51 PM, Daniel J Sebald wrote:

> On 01/30/2015 11:15 AM, Rik wrote:
>> On 01/30/2015 08:13 AM, [hidden email] wrote:
>>> Subject:
>>> Re: Keeping the gui-release branch open considered harmful
>
> [snip]
>
>> But the original comment still stands.  If someone is willing to merge
>> the two branches and everyone feels that classdef and the new audio
>> system are ready for release then I won't stand in the way.
>
> What is the history of classdef?  It looks to me that it was a separate
> branch and then merged and truncated in December 2013.  After that,
> there is only sporadic activity related to classdef and it is in default
> branch.
>
> It's been around a while.  Is it that GUI code the first major use of
> classdef?

No, the GUI doesn't use classdef (yet).

Octave core does use classdef to provide the inputParser function, so we
can't just disable it.

jwe



Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

John W. Eaton
Administrator
In reply to this post by Rik-4
On 01/30/2015 12:59 PM, Rik wrote:

> Yes, it's a bit of a pickle either way.

Yeah.  Well, it would be simpler if we could just work on one feature at
a time and make releases when each feature is complete.  :-)

> You seemed to have much better
> luck than I did quickly generating the backout changesets so maybe that is
> the way to go.  I didn't see the file NEWS in the diff, so maybe that has
> to be manually modified to reflect what has been kept and what has not.

Oh, yeah, of course.  The reason it didn't show up in the diff that I
generated is because it was not modified at the same time as the
functions were removed, so that is a separate changeset to backout.

> I
> also like to put the version number when a function was deprecated in the
> m-file in scripts/deprecated/*.m.  Those should be changed to 4.0 instead
> of 4.2.

OK, I missed that too, but will fix it.  Thanks.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

John W. Eaton
Administrator
On 01/30/2015 03:48 PM, John W. Eaton wrote:

> On 01/30/2015 12:59 PM, Rik wrote:
>
>> Yes, it's a bit of a pickle either way.
>
> Yeah.  Well, it would be simpler if we could just work on one feature at
> a time and make releases when each feature is complete.  :-)
>
>> You seemed to have much better
>> luck than I did quickly generating the backout changesets so maybe
>> that is
>> the way to go.  I didn't see the file NEWS in the diff, so maybe that has
>> to be manually modified to reflect what has been kept and what has not.
>
> Oh, yeah, of course.  The reason it didn't show up in the diff that I
> generated is because it was not modified at the same time as the
> functions were removed, so that is a separate changeset to backout.
>
>> I
>> also like to put the version number when a function was deprecated in the
>> m-file in scripts/deprecated/*.m.  Those should be changed to 4.0 instead
>> of 4.2.
>
> OK, I missed that too, but will fix it.  Thanks.
I'm attaching an updated patch.  I also fixed the version number in
configure.ac.

jwe



diffs.txt (44K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Keeping the gui-release branch open considered harmful

Daniel Sebald
In reply to this post by John W. Eaton
On 01/30/2015 02:45 PM, John W. Eaton wrote:

> On 01/30/2015 12:51 PM, Daniel J Sebald wrote:
>> On 01/30/2015 11:15 AM, Rik wrote:
>>> On 01/30/2015 08:13 AM, [hidden email] wrote:
>>>> Subject:
>>>> Re: Keeping the gui-release branch open considered harmful
>>
>> [snip]
>>
>>> But the original comment still stands. If someone is willing to merge
>>> the two branches and everyone feels that classdef and the new audio
>>> system are ready for release then I won't stand in the way.
>>
>> What is the history of classdef? It looks to me that it was a separate
>> branch and then merged and truncated in December 2013. After that,
>> there is only sporadic activity related to classdef and it is in default
>> branch.
>>
>> It's been around a while. Is it that GUI code the first major use of
>> classdef?
>
> No, the GUI doesn't use classdef (yet).
>
> Octave core does use classdef to provide the inputParser function, so we
> can't just disable it.
OK, well if making a release means an inordinate amount of
re(de)construction, I'd say go with the other option of merging and then
everyone search for bugs over the course of a couple weeks.

Windows development: Maybe a separate branch for that, say,
"windows-install" branch (the GUI might have some odd cases where it is
Windows specific dependent).  There are a couple reasons.  It would keep
Windows related items off of the stable/default branch until it is
ready.  Someone working on the Windows install wouldn't have to always
be updating their Mercurial repository with the latest code.

One thing that could be done with versioning is to associate the minor
version (i.e., second number) only with the stable/default branch.  And
then minor-minor versions would be variants of different branches.  It's
hard to describe, but I've drawn a little picture of a hypothetical
example.  Is it possible to merge things in such a way as shown in the
picture?  With such a setup there is an issue with the minor-minor
number correlating with exactly might be contained in the release.  A
solution to that might be to use a version with a hyphenated branch
name, e.g., 4.0.1-windows.  Advancing the minor number, e.g., from 4.0.x
to 4.1.x would inherently trigger several minor-minor releases, but if
the merging is conflict free it wouldn't be such a problem.

Dan

versioning.png (11K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

No

Michael Godfrey

On 01/30/2015 05:07 PM, Daniel J Sebald wrote:
> Windows development: Maybe a separate branch for that, say,
> "windows-install" branch
Time ti just put a stop to this. Remember the GU branch?


Reply | Threaded
Open this post in threaded view
|

Re: No

Daniel Sebald
On 01/30/2015 07:40 PM, Michael Godfrey wrote:
>
> On 01/30/2015 05:07 PM, Daniel J Sebald wrote:
>> Windows development: Maybe a separate branch for that, say,
>> "windows-install" branch
> Time ti just put a stop to this. Remember the GU branch?

There's nothing inherently wrong with branches, so long as things are
kept separate.  The problems arose in this case because of the periodic
merging of branches.  John wouldn't have made the mistake of putting Qt
print code in the default branch had the GUI remained separate all along
because his Qt code wouldn't have compiled or worked in the default branch.

If the Windows code goes into the default branch at the onset and is in
a constant flux it could mean a higher version release rate if you want
people with Windows access to test.  But that means everything in
default branch needs to be robust when there could be other development
things going on.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: No

Michael Godfrey

On 01/30/2015 08:59 PM, Daniel J Sebald wrote:
> If the Windows code goes into the default branch at the onset and is
> in a constant flux it could mean a higher version release rate if you
> want people with Windows access to test.  But that means everything in
> default branch needs to be robust when there could be other
> development things going on.
Another benefit of no branches.


Reply | Threaded
Open this post in threaded view
|

Re: No

Daniel Sebald
On 01/30/2015 08:13 PM, Michael Godfrey wrote:
>
> On 01/30/2015 08:59 PM, Daniel J Sebald wrote:
>> If the Windows code goes into the default branch at the onset and is
>> in a constant flux it could mean a higher version release rate if you
>> want people with Windows access to test. But that means everything in
>> default branch needs to be robust when there could be other
>> development things going on.
> Another benefit of no branches.

The drawback is the reluctance to make significant and good changes when
warranted.

Dan

Reply | Threaded
Open this post in threaded view
|

Re: No

Michael Godfrey

On 01/30/2015 09:24 PM, Daniel J Sebald wrote:

> On 01/30/2015 08:13 PM, Michael Godfrey wrote:
>>
>> On 01/30/2015 08:59 PM, Daniel J Sebald wrote:
>>> If the Windows code goes into the default branch at the onset and is
>>> in a constant flux it could mean a higher version release rate if you
>>> want people with Windows access to test. But that means everything in
>>> default branch needs to be robust when there could be other
>>> development things going on.
>> Another benefit of no branches.
>
> The drawback is the reluctance to make significant and good changes
> when warranted.
>
> Dan
Correct. But the advantage is a reliable system which can be developed
without continuing
regressions and failures. Recall that "significant and good" is not the
same as correct at the
system level.



123