[RFC] Release Strategy Following 3.1

[imkingdavid]

In the Falling Behind topic on the main phpBB discussion forums, I posted about a new release strategy that, potentially might work better by decreasing time between feature releases as well as decreasing the size of each release.

For 3.1, the way I see it, the release strategy was "Okay, let's make a long list of features we want to be in the next version (i.e. feature freeze) and not release until they are all ready". Well, they're not all ready and we're pushing for a release following the implementation of extensions and hooks (and related co-requisites) because it's taken so long to get to this point.

On the other hand, completely time-based releases are not realistic for our amount and frequency of contributions. Having internal, soft deadlines could somewhat improve timing, but moving to a time-based release strategy would not work out.

I propose moving to a hybrid between the two. Instead of piling 20 new features into a release, we could release when new features are ready but limit it to once every X months (6?) to keep from having tons of releases back to back, and basically include whatever is ready by that point in the release. Of course minor releases for bug fixes could occur more frequently, or else bug fixes just get packaged with the feature releases.

Not only does this increase the frequency of feature releases, it also decreases the amount of time between idea conception and implementation (so users get new features sooner without having to wait for four other features to be ready as well).

I know this may not be the exact way to do it, but this is how I am thinking it could be done. If there are holes in my proposal, I'd love to hear them. Ultimately, the idea is to keep releases coming more often (but not too often) so that the userbase remains happy with the software.

[Oleg]

The idea was to have a feature freeze (for the next release) some fixed time after a feature release, and to actually have implemented features by the feature freeze. Basically feature freeze is when we start stabilizing the release, e.g. given our (good) quality situation we would immediately release alpha 1 right then and there.

The problem with 3.1 was that we predicated release on a feature which was nowhere near ready by feature freeze date (hooks). As long as we don't do that again we should be able to do frequent (enough) releases just fine. If we do that again, no guarantees.

In terms of release frequency, we do maintenance releases roughly every 6 months each release takes probably about a month to actually get released. I would be weary of trying to release more frequently. Maybe try setting feature freeze at 12 months past a feature release with the goal being feature releases every 18 months.

Of course, if contribution picks up we can compress these timeframes.

[Jacob]

As I see it, one feature release in 1 year is acceptable, more than that, ummm...
If the features are related, great, if not, don't bother to much.
Also, try to include in each feature a medium/big improvement (from the users perspective). That probably will keep people happy.

The problem with 3.1 was that we predicated release on a feature which was nowhere near ready by feature freeze date (hooks). As long as we don't do that again we should be able to do frequent (enough) releases just fine. If we do that again, no guarantees.

The problem is that one can always think "Nah, I can finish this in a couple of days, let's include this in the release", but then life happens and somebody doesn't have time, somebody else don't like the feature and don't want to work on it, etc.

Instead of saying "the next release will have these features, but we don't know when", let's say "the next release will be in a year, but we don't know wich features it will have". You can say, "we'll try to release it with <feature X> or <feature Y>", but as I said earlier, don't bother to much if you can't do it, it will have to wait 'till the next release.

I think it will help a lot if you just say every once in a while what's happening. Maybe post an announcement or something explaining that you're working on <feature X> and you're going to postpone the next release for a few months untill it's implemented. Just an example.
The posts by imkingdavid in the falling behind topic were really helpfull in that regard, in my opinion.

[Ger]

Is it really necessary to have a feature release so often?

I mean, when 3.1 is done, the current users (board admins) will be split in 2 groups; a group that updates very quickly and a group with boards that are heavily modded who are afraid of updating. Of course there will be an automatic updater, but we all know what happened when 3.0 came out.
The major plus on 3.1 compared to 3.0 is the hook system. One can have a very basic installation of 3.1 while still having tons of hooks installed. IMO, it doesn't make sense to update a heavily modded board to 3.1 and still keep those MODS installed. People would rather wait until their MODS for 3.0 are available as hooks for 3.1. This process takes time, it's as simple as that. So when 3.1 is stable it will at least be a year before [3.1 + hooks] suits the needs for board admins with [3.0 + MODS], probably longer.

When 3.2 is released in 6 months after 3.2, the community will ask for support for 3 versions. There will also be the demand for a MOD/hook section for 3 versions and a style section for 3 versions. This will require much from the team. Is that what you really want?

Also, will there be a need for feature additions in 3.1 as part of the core? With the hook system, most features can be added as hooks. Users (admins) can simply search Titania for the feature they need and than install it, preventing bloat. Therefore I think that the only real development for 3.x at that point should be further stabilization and optimization of the core or additional hook points. This will result in 2 stable branches and therefore 2 supported branches. Development effort can then be pointed at 4.x, which will be much more rewarding than working at another 3.x branch.

[MichaelC]

Is it really necessary to have a feature release so often?

I mean, when 3.1 is done, the current users (board admins) will be split in 2 groups; a group that updates very quickly and a group with boards that are heavily modded who are afraid of updating. Of course there will be an automatic updater, but we all know what happened when 3.0 came out.
The major plus on 3.1 compared to 3.0 is the hook system. One can have a very basic installation of 3.1 while still having tons of hooks installed. IMO, it doesn't make sense to update a heavily modded board to 3.1 and still keep those MODS installed. People would rather wait until their MODS for 3.0 are available as hooks for 3.1. This process takes time, it's as simple as that. So when 3.1 is stable it will at least be a year before [3.1 + hooks] suits the needs for board admins with [3.0 + MODS], probably longer.

When 3.2 is released in 6 months after 3.2, the community will ask for support for 3 versions. There will also be the demand for a MOD/hook section for 3 versions and a style section for 3 versions. This will require much from the team. Is that what you really want?

Also, will there be a need for feature additions in 3.1 as part of the core? With the hook system, most features can be added as hooks. Users (admins) can simply search Titania for the feature they need and than install it, preventing bloat. Therefore I think that the only real development for 3.x at that point should be further stabilization and optimization of the core or additional hook points. This will result in 2 stable branches and therefore 2 supported branches. Development effort can then be pointed at 4.x, which will be much more rewarding than working at another 3.x branch.

People remember phpBB 2.0 to 3.0 but then they would always lose ALL of their MODs.
1) Almost everything was pretty much re-writen so no code would still work.
2) It didn't update your set of files, it made a new set of files then offered to convert your old database.

[Ger]

I know that. You know that. Most of the active users on Area51 and the main phpBB forums know that. However, we are just a small -better yet: a tiny- part of the board admins that use phpBB. The majority of phpBB admins don't know that. They'll probably see a release announcement and think:
Hey, a new release. Let's check it out. Hmmm... Do I really need those features? Can I upgrade? Yes, but it can be a pain in the ass... Oh, 3.0 will be maintained, so I'll stick to that.
Many admins are already afraid of updating from 3.0.x tot the next maintenance release, even without any MODs. Half of the admins with several MODs are very afraid of updating in 3.0.x, so a very significant group will be terrified of upgrading to 3.1.

Note: this was only part of my argument. Since you only try to dismiss that point, can I assume you agree with the rest?

[MichaelC]

I know that. You know that. Most of the active users on Area51 and the main phpBB forums know that. However, we are just a small -better yet: a tiny- part of the board admins that use phpBB. The majority of phpBB admins don't know that. They'll probably see a release announcement and think:
Hey, a new release. Let's check it out. Hmmm... Do I really need those features? Can I upgrade? Yes, but it can be a pain in the ass... Oh, 3.0 will be maintained, so I'll stick to that.
Many admins are already afraid of updating from 3.0.x tot the next maintenance release, even without any MODs. Half of the admins with several MODs are very afraid of updating in 3.0.x, so a very significant group will be terrified of upgrading to 3.1.

Note: this was only part of my argument. Since you only try to dismiss that point, can I assume you agree with the rest?

I'll reply to the other half then .
I would think 6 months might be too short a time-span. Maybe one year might be more appropriate.

My guess is that Olympus will be EOL'd after about 8-10 months but it would almost certainly be by the time of the 3.2 release (which ever is first) as phpBB wouldn't support 3 branches at the same time.

As for MODs/Styles, as far as I know (maybe a MOD/Styles Team member can confirm/deny this), when Titania starts accepting contributions for 3.1, you will not be able to submit contributions for 3.0. Titania doesn't support it and when I enquired as to whether multi-version support would be required (so it could be developed in time), I was told the plan was to only accept submissions for one version.

Not everything can be added with MODs, for example big file changes such as changing the URL to the license had to wait until 3.1 because it changes every file, but why would you get this in a MOD? Also, most people prefer to have a feature in the core than use extensions/MODs. And there are some things that aren't extensions/MODs. For example prefixing classes, changing coding guidelines, updating jQuery.

[Arty]

I think frequent releases is a bad idea for phpBB.

phpBB is available in almost all automatic installers on hosts. They do not update their software too often, so it is very common to see them few versions behind. With frequent release cycles it will be very common to have new forums that are 2-3 major versions behind, not being able to find mods/styles compatible with their versions. At the end developers of those installers might end up switching to other forum software, which will be a big blow to phpBB.

Style and mod authors will have to update their work way more often. It requires a lot of effort, so some authors might just abandon their releases, resulting in fewer styles and mods.

[Jacob]

With frequent release cycles it will be very common to have new forums that are 2-3 major versions behind, not being able to find mods/styles compatible with their versions.

I don't see why a feature release would make a Mod incompatible with the previous release, if such a Mod use hooks and these don't change. (You could add more, but removing ones already there wouldn't make sense, I suposse).

Of course if the feature release breaks compatibility, wait longer, if not, I think 1 year is a very acceptable time frame. Maybe I'm missing something, though..

[Arty]

I don't see why a feature release would make a Mod incompatible with the previous release, if such a Mod use hooks and these don't change. (You could add more, but removing ones already there wouldn't make sense, I suposse).

Of course if the feature release breaks compatibility, wait longer, if not, I think 1 year is a very acceptable time frame. Maybe I'm missing something, though..

Because authors usually don't maintain obsolete releases and download websites rarely list anything other than latest versions.