Keeping the gui-release branch open considered harmful (was: Re: Release Ideas)

[John W. Eaton]

On 01/27/2015 10:48 PM, Michael Godfrey wrote:
> On 01/27/2015 07:35 PM, John W. Eaton wrote:
> > On 01/27/2015 06:40 PM, Michael Godfrey wrote:
> >
> > > Unless there is something blocking default, why not just make one
> > > release (default already has all the
> > > GUI code).
> >
> > We deprecated some things in 3.8 that have already been removed from
> > default but not gui-release.  Normally we have one release that still
> > contains the deprecated functions but warns if they are used. Skipping
> > the gui-release release and going straight to default would break this
> > promise that we normally make.  Not a huge thing, I suppose, but
> > something we should consider if we decide to just release default.
> >
> > jwe
> That is a concern. But, it might make sense to amend the deprecated
> functions rule to 1 release or some
> substantial length of time since the deprecated announcement.
> A compromise might be to make the GUI  branch at the point it is closed
> available for download for anyone who depends on the deprecated
> functions, but go ahead with the
> "official" release of the default. This would make the benefits of the
> default available and close down
> the 2 versions under development problem.
>
> I am confident that practically all users will be happier with the
> default branch.

Executive summary:

We should just merge gui-release to default one last time and close 
gui-release as the gui-release branch has become more of a hassle than 
it is worth.

Rant:

While working on making printing work for Qt widgets, I wanted to do a 
little code refactoring.  I wasn't paying close attention and was 
working on default even though I should have been on gui-release because 
these changes need to be done for the first release with the GUI.  When 
I noticed my mistake, I thought I would just move my changes over to 
gui-release, then merge them back to stable.  But my changes did not 
apply cleanly to gui-release because there were significant differences 
between gui-release and default for the functions I was working on.  So, 
I could continue, clean up the patches so they work with gui-release, 
merge them to default, fix up the conflicts (AGAIN!) and then go on 
hating my day and the fact that I ever thought up this idea of a third 
branch of development.

Even if I had started working on gui-release, I would have faced the 
same problem of conflicts when merging from gui-release to default 
because I was making changes where the code has diverged.

This is not the first time I've had trouble like this, and I'm sure it 
won't be the last if we continue to keep both gui-release and default open.

Yes, we still have the same problems with stable and gui-release (or 
default), but we aren't making many changes to stable, so these 
conflicts don't come up as often.

So, instead of fighting this battle again and again, we could just save 
ourselves a lot of confusion and wasted time and drop this idea of a 
release from gui-release.

An offer I'll probably regret:

I'd even be willing to spend a little bit of time restoring the 
deprecated functions that have been removed in default (at least the 
ones for which that's a relatively trivial job).

And finally, an optimistic statement that will probably turn out to be 
completely false:

I don't know for sure since I haven't tried it, but I think that 
restoring the deprecated functions that were removed on the default 
branch should just be a matter of backing out some changesets that were 
made soon after the gui-release branch was created.

jwe