Perhaps I'm over optimistic naturally, but personally I think that getting to a release cycle of around six months would be really very nice.
Twelve months is a long time. For instance, 1.2 is now ancient history. Many of our developers encourage people to play development releases instead of 1.2. Feedback from users based on 1.2 is now of little value. I also do think the length of time to get a feature used by a broad base of users is frustrating, and leads to a longer 'feedback loop' which reduces overall productivity. Additionally, I think a long cycle has a psychological effect of causing people to think "it doesn't matter if I break things really badly now with this new feature...the next stable release is ten months away!" I don't think this attitude is healthy; we should strive to keep every development release as stable as possible. If you can't develop a releasable step of a feature in a three month period, then your feature is probably too complicated. Personally I'm in favor of this. I think it'd be a win for both developers and users. We should cut down on "time to stabilize" for a release by always working hard to never allow things to become too unstable in the first place. David On Sun, 2008-03-02 at 09:06 -0500, Eric S. Raymond wrote: > I think we should shorten our stable-release interval to 6 months. > > This is not a conclusion I have arrived at casually or quickly. I've > been observing this project for nine months now. I think it suffers > from some of the well-known problems associated with long release > intervals, including (1) too many feature additions in each cycle to > debug thoroughly in pre-release time, and (2) a marked tendency to > stagnation and drift in mid-cycle. (In retrospect, I think it was in > a stagnant period when I joined -- and I think the commit-frequency > graphs on Ohloh confirm this.) > > I have observed that the long interval also subtly damages our > relationship with our user and tester base, as well. Most players > stick with the prepackaged stable version, which means the expected > dwell time for user-visible bugs is *far* too long. > > Late last year I lost some initial members of my UI test group simply > because 1.4 was too far in the future to sustain their interest -- > they weren't going to get to see the fruits of their labor soon > enough, lost motivation, and drifted away. (This is what specifically > started me thinking our release interval is a problem.) > > Given the choice, I would plan as follows: > > Present -> May 1: Open development > > May 2 - May 9: "Week of Bug-Stomping" -- soft feature freeze in effect > > May 10 -> 2 July: Open development > > 2 July -> 2 Aug: Feature freeze, bug stomping, translations > > 2 Aug: 1.6 release > > I think 1.6 will actually be in a better state if we shorten the cycle > and stick to less ambitious feature goals in 1.5. (This doesn't mean any > of them would need to be abandoned, just postponed to 1.7.) > > Finally, I think our long release interval has been meshing badly with the > timing of Linux distribution releases. While I consider this a minor point > relative to my previous ones, I think it is not insignificant. _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
