XTF wrote:It doesn't really matter what you call it. So: Any plans to release 3.1 this year?
You won't like this, but we plan to release it when it's ready. I would love to say that yes, it will be this year. But that all depends on whether or not the things we are hoping to complete get done by then. Please don't think that I wouldn't like to see phpBB 3.1 done sooner than later. I would love it if we could all work all day, every day, and get the release out. But the reality is that this takes time; each feature goes through the following phases, often repeating some as it goes: discussion/design, development, testing, merge. Each of those (except, perhaps merge, although that includes final testing) takes time.
(To note: the following is not meant to excuse the slow development speed, but rather to explain the facts of why it is how it is, as I see it.)
Here's the deal: development speed will not change with the enforcement of a deadline. The bottom line is that while we (developers) try to dedicate as much time as we can to progress on the next version, we are ultimately restricted by the time we have to spend on other things (e.g. paid work/our jobs, family/personal life, other projects we may help with, etc.). A deadline will cause one of two things: 1) rushed, broken, and low-quality software that only mostly works, or 2) we miss the deadline because we don't have everything ready on time.
One of the issues that I think has caused 3.1 to take such a long time, aside from the availability problem outlined above, is the release strategy. From what I can remember, when the development team originally sat down to get 3.1 started, they said "let's compile a list of features and not release until all of these features are completely done". In my opinion, that kind of development strategy is flawed. Yes, it is necessary when you are initially designing the software from the beginning to lay out what features you want and decide what is needed for inclusion in the first release, but for subsequent feature releases, if you wait for all X number of features to be done, it is going to (as you can see) take a long time.
A better release strategy, in my opinion, is a "Let's release every X months, assuming there have been enough new changes to justify a feature release. Whatever is done is included; everything else is pushed back." In other words, instead of trying to include everything and the kitchen sink, we would only include what is ready. So it's more of a loose time-based release than a feature-based release. Let's say we just released a feature release and I finish feature A. That is put into the deveopment branch for the next feature release. I start on feature B and if I finish by the time the next release comes, it is included along with feature A. Otherwise, we wait until the next release for it.
The current development strategy is something of a hybrid of the two; there are a few things that must be done before a release, but the rest is just whatever makes it. If you have been around for a little while, you may have noticed the reorganization of the forums; we had 3.1 RFCs and 3.2 RFCs separated. However, because we are now including whatever is done when we release, rather than labeling a feature with a specific version number, that organization is not optimal (it resulted in having to move topics from the 3.2 RFC forum to the 3.1 RFC forum upon completion).
