Maintenance branches and minor releases?
Moderator: Committer
Maintenance branches and minor releases?
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!
- adrian_broher
- Programmer
- Posts: 1156
- Joined: Fri Mar 01, 2013 9:52 am
- Location: Germany
Re: Maintenance branches and minor releases?
For reference: A somewhat related discussion already happend some time ago:
http://www.freeorion.org/forum/viewtopi ... ase#p86533
But in general I agree. It would be nice to have bugfix releases.
http://www.freeorion.org/forum/viewtopi ... ase#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
Attached patches are released under GPL 2.0 or later.
Git author: Marcel Metz
Re: Maintenance branches and minor releases?
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?
If our core devs are willing, we can give it a try for 0.4.7.
Comments, opinions?
Re: Maintenance branches and minor releases?
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
Re: Maintenance branches and minor releases?
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.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.
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.
Any code or patches in anything posted here is released under the CC and GPL licences in use for the FO project.
Re: Maintenance branches and minor releases?
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.
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.
Re: Maintenance branches and minor releases?
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.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.
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
Re: Maintenance branches and minor releases?
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.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.
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.
Re: Maintenance branches and minor releases?
Yes, I meant it to be a concrete example of how many/few commits would qualify for cherry-picking.Dilvish wrote:(Though perhaps you simply mention that to illustrate how such bug fixes might be a major headache?)
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.