Re: Keeping the gui-release branch open considered harmful

[Daniel J Sebald]

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, address@hidden 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
Description: PNG image