Code Freeze Policy? #12150
Replies: 4 comments 3 replies
-
@Cernelius one saying about code freezes, "after code freeze comes bug thaw." This forum thread went into detail on the changing deployment & release strategy: |
Beta Was this translation helpful? Give feedback.
-
Now it works. I remember I saw that, but then I completely forgot. I guess my suggestion can be reworded as a one-time thing for this release only then (not to add features for now if the release is a few months ahead). I'll have to re-read it and don't remember if I replied, but I think that maybe I tend to agree because (as a map-maker) remaining stuck for years between significantly different released and to-be-released versions is terrible. |
Beta Was this translation helpful? Give feedback.
-
So here are my thoughts: I am of the strong opinion that we should try to get 2.6 released asap (fixing whatever blockers remain). However, I think small improvements can still be OK - and I wouldn't necessary block things like the pending purchase save game support that was just added, since the change ended up being pretty small - and yes it introduced an issue, but it was a pretty benign / easy fix. Of course, if we're really at the point where we would be a week or days away from a release, I can see the argument for blocking those too. All in all, I'd like us to reach a new "stable milestone" with the release of 2.6 so that we can clean out the bug database of old pre-2.6 issues and use that as the new baseline for determining regressions, etc. Separately, I'm not actually convinced of the "every change is a release and everything must be backwards compatible" proposal by Dan, but that's for after the 2.6 release and we can discuss more later. I'd rather we go with some predictable release schedule (e.g. quarterly) from HEAD and have the flexibility to break backwards compatibility sometimes. Especially since the engine still uses some fragile formats like Java serialized objects, that would really lock us into the current class model if we have to keep backwards compatibility indefinitely. If we get away from those and just have actual data formats, then I can see backwards compatibility being more reasonable to maintain, though. (Having said that, I do think breaking backwards compatibility shouldn't be done lightly, I just disagree that we should never break it.) Anyway, those are my 2c. |
Beta Was this translation helpful? Give feedback.
-
Yeah, I think it has been amply proved that quarterly or whatever release schedules have failed again and again, and I don't even remember how many years the 2.6 release is overdue... In a project in which anyone can walk away any time, you probably have to release any time as the pain of having wildly unpredictable release times is going to be greater than the still likely egregious and chronic unreliability of a constant release model. Any opinions on whether 2.6 would warrant being numbered 3.0 upon release (also for entering a new release model era)? |
Beta Was this translation helpful? Give feedback.
-
@Cernelius said in #12140
Beta Was this translation helpful? Give feedback.
All reactions