FreeOrion

Forums for the FreeOrion project
It is currently Sat May 27, 2017 3:36 pm

All times are UTC




Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Sun Apr 09, 2017 6:12 pm 
Offline
Space Floater

Joined: Thu Oct 06, 2016 3:19 pm
Posts: 25
I'm fed up with all the boost-related breakages i encounter when trying to bisect a bug. I propose the release maintenance branches that you can rebase on some commit in the middle of the development one to get all the boost and other external environment-related fixes. Also this would fix the situation when we don't have a release that works on a modern environment and people come on the forum and complain about it; instead it would make sense to make minor releases from the maintenance branch.

_________________
Team S.M.A.C.: play multiplayer with us!


Top
 Profile  
 
PostPosted: Sun Apr 09, 2017 6:48 pm 
Offline
Programmer
User avatar

Joined: Fri Mar 01, 2013 9:52 am
Posts: 1030
Location: Germany
For reference: A somewhat related discussion already happend some time ago:

viewtopic.php?f=24&t=9509&p=86558&hilit=release#p86533

But in general I agree. It would be nice to have bugfix releases.

_________________
Resident code gremlin
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz


Top
 Profile  
 
PostPosted: Mon Apr 10, 2017 6:45 am 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4028
Location: Sol III
As I said in the thread Marcel linked to, it's not that I don't want to do bugfix releases. Of course that would be a nice thing to have. It's the added workload that's the problem here, and as I also mentioned in that thread, I'd definitely need the support from the rest of the team to pull that off.

If our core devs are willing, we can give it a try for 0.4.7.

Comments, opinions?


Top
 Profile  
 
PostPosted: Mon Apr 10, 2017 11:22 am 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4209
Of course my first thought is that alpha software doesn't have maintenance versions. But FO is an unusual case of alpha software. If we're talking about limited bugfixes to deal with major things like boost updates that break the most recent release, then that seems like a fairly modest scope that we could reasonably contemplate.

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Mon Apr 10, 2017 6:06 pm 
Online
Creative Contributor
User avatar

Joined: Fri Jun 28, 2013 11:45 pm
Posts: 3091
Dilvish wrote:
Of course my first thought is that alpha software doesn't have maintenance versions. But FO is an unusual case of alpha software. If we're talking about limited bugfixes to deal with major things like boost updates that break the most recent release, then that seems like a fairly modest scope that we could reasonably contemplate.

Yeah, what we currently have is a fully playable game that's enjoyable and feature rich that's also nowhere near completion. Which means we're going to have players/groups of players that would prefer to stick to the formal 'stable release' but get updates if we fix problems.

I have zero clue what this entails but it does make sense to try it to see if it's workable: if someone manages to find that edge-case Windows mouse-pointer disappearing issue that only happens on certain hardware configurations, for example, we ought to push that out to the most recent Release.

_________________
Mat Bowles

Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.


Top
 Profile  
 
PostPosted: Tue Apr 11, 2017 7:12 pm 
Offline
Programmer

Joined: Mon Feb 29, 2016 8:37 pm
Posts: 145
Has anyone counted the number of commits between 0.4.6 and 0.4.7 that this would have applied to, in order to gauge the amount and feasibility of the additional work?

By feasibility, I mean, if the commits come after the transition to C++11, or some other significant refactoring, then adding them to the release branch is not as simple as a cherry pick.


Top
 Profile  
 
PostPosted: Tue Apr 11, 2017 7:47 pm 
Offline
AI Lead, Programmer
User avatar

Joined: Sat Sep 22, 2012 6:25 pm
Posts: 4209
LGM-Doyle wrote:
Has anyone counted the number of commits between 0.4.6 and 0.4.7 that this would have applied to, in order to gauge the amount and feasibility of the additional work?
By feasibility, I mean, if the commits come after the transition to C++11, or some other significant refactoring, then adding them to the release branch is not as simple as a cherry pick.
I don't know that we agreed on a scope of issues to even try counting. The very limited scope that I was envisioning was something that I would expect to be in the small handful range. I don't think we should have any blanket commitment for bugfixes, and could just consider them as they come up, with respect to severity of bug and if the fix can be cherry picked or easily adapted.

And at this point I don't think there is any point talking about a bug-fix release for 0.4.6; either 0.4.7 can fill that need or they can do without. (Though perhaps you simply mention that to illustrate how such bug fixes might be a major headache?)

_________________
If I provided any code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0


Top
 Profile  
 
PostPosted: Wed Apr 12, 2017 4:08 pm 
Offline
Release Manager, Design
User avatar

Joined: Wed Nov 16, 2011 12:56 pm
Posts: 4028
Location: Sol III
Dilvish wrote:
I don't think we should have any blanket commitment for bugfixes, and could just consider them as they come up, with respect to severity of bug and if the fix can be cherry picked or easily adapted.
Pretty much this. The idea is to provide bugfix releases for bugs that are both severe enough to warrant the extra effort involved, and aren't too hard to cherry pick. So, e.g. a fix that can't be cherry picked without also cherry picking a huge refactoring which took place after the release and before the fix went in will not meet that condition.

Anything beyond that will probably be too difficult to handle with the resources at our disposal, IMO. It would divert too much time and efforts from regular dev work.


Top
 Profile  
 
PostPosted: Wed Apr 12, 2017 5:25 pm 
Offline
Programmer

Joined: Mon Feb 29, 2016 8:37 pm
Posts: 145
Dilvish wrote:
(Though perhaps you simply mention that to illustrate how such bug fixes might be a major headache?)

Yes, I meant it to be a concrete example of how many/few commits would qualify for cherry-picking.

I agree with the prevailing sentiment, that each case should be considered in turn for severity, range of player base affected and easy of cherry picking.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group