Re: vBulletin Support Schedule

[lim (x³-7x²) = ∞]

Accordings to vBulletin Support Schedule we have this levels of support (where 4.x last release before 5.0):

Current   5.0   Full Support
V(-1)     4.x   Bug + Security        

Current   5.1   Full Support
V(-2)     4.x   Security Only

Current   5.2   Full Support
V(-3)     4.x   No Support

Can you extend this information to cover 5.* development period, Alpha period, Beta perios, RC perios, Gold period?

Will it be like with 4.* release? Something will be improved? May be I am missing something?

Current   5.0   Development
V(-0)     4.x   Bug + Security, limited (1 support staff, like with 3.* during 2009)

Current   5.0   Alpha
V(-0)     4.x   Security Only

Current   5.0   Beta
V(-0)     4.x   Security Only

Current   5.0   RC
V(-0)     4.x   Security Only

Current   5.0   Gold
V(-1)     4.x   Bug + Security, limited (?, like now)

Current   5.1   Full Support
V(-2)     4.x   Security Only

Current   5.2   Full Support
V(-3)     4.x   No Support

I am interested to know because Ray Morgan suggested on 18th June 2009 "18 months from now I would hope we're knocking on the door of vB5" (wich is 1 year from now)

[Colin F]

Pre-release versions don't impact the support schedule - support changes when Gold is released.

[lim (x³-7x²) = ∞]

What about Scheduled Maintenance Releases?

In order to make our maintenance release schedule more predictable for customers, and in an attempt to ensure that bug fixes are passed on to users in a timely fashion, we will now be implementing a regime of pre-scheduled maintenance releases.

A maintenance release is classified as one that contains day-to-day bug fixes that do not include serious data loss issues or security flaws. They are designated (usually) by an incrementing of the third version digit, such as 3.7.1, 3.7.2, 3.7.3 etc.

From now on, the longest time customers will ever wait for bug fixes to be released will be two months.

Toward the end of each month, the developers will evaluate the quantity and severity of the bugs found and fixed in the previous month. If there has been an abnormally high number of bugs reported, or the severity of some of the bugs fixed is considered to warrant an early release, the next maintenance version will be brought forward and will be released to customers on the final Tuesday of that month.

If the quantity and severity of bugs is not unusual, the maintenance version will be released on the final Tuesday of the month, two months following the previous maintenance version.

Steve Machol tell us something else:

"There are no critical bugs in 3.8.5, therefore this is simply a lower priority than vB4 at this time."
"There are no bugs that are so serious they are causing major problems for any significant number of customers."

There are bugs wich was reported to stable version, but they are fixed in alpha first (like 28714).

[Paul M]

3.8.5 will come when it comes, the schedule above (every two months) went out the door about six months ago.

As Steve says, there are no significant bugs anyway, so it doesnt really matter - people are happily running 3.8.4 without problems.

[lim (x³-7x²) = ∞]

I will not go into 3.x discussion, I just want to confirm this is new standard of vbulletin, and we can expect the same during 5.x release cycles (delaying 4.x maintenance releases)

I got a PM from Ray in replying saying 3.x maintenance releases should be continuing after vB 4.0 GOLD is out!

[Ryan Ashbrook]

3.8.5 will come when it comes, the schedule above (every two months) went out the door about six months ago.

As Steve says, there are no significant bugs anyway, so it doesnt really matter - people are happily running 3.8.4 without problems.

Lol, my forum has never run better at present, to be honest.

[Wayne Luke]

It is too far in the distance to update the schedule to include 5.X versions. It is meant as a representation of what the support schedule will be like without locking us into a particular version progression.

[lim (x³-7x²) = ∞]

Right now we have some interesting news, which makes this thread relevant again.


First, now we have announced vb5 plans (which gives us the same vb5 timing as Ray Morgain suggested).

That means Wayne Luke answer is now outdated, and it will be very interesting to know how you will distribute resources between vb4 and vb5 during next stages of development.


Second, now we have good example of how effective was single-person-support during next-major-release-alpha-development - we have serious security bug reported on 17th august 2009 fixed silently on 13th july 2010 without notice (with september raise of hacking attacks on vbulletin 3)

Last year Steve Machol incompetently answered 'There are no bugs that are so serious they are causing major problems for any significant number of customers.' to my question 'does it mean that someone actually reviewed all bugs submitted for 3.x during last month? (just to make sure none of them are critical)


We already know project leader already spending some of his time on planning vb5 great features, but even more interesting will be to know how much coders will be doing vb5 vs vb4 work (not right now, when development started).

So, will you fix vb4 bugs when vb5 will be on alpha stage, or security problems can be delayed because lower priority? Will it be single person like it was with vb3 during vb4 development, or you re-evaluated something? With new licensing structure it looks like resource distribution and timing must be already roughly planned and you probably already know what kind of support changes to expect...

[Paul M]

Last year Steve Machol incompetently answered 'There are no bugs that are so serious they are causing major problems for any significant number of customers.' to my question 'does it mean that someone actually reviewed all bugs submitted for 3.x during last month? (just to make sure none of them are critical)

That "bug" is not the same issue. The current exploit is using a null character to fool mysql into adding the exact same username into the database. The bug you linked to is using characters that either dont display, or display similar to normal chars to make a username look similar, when in fact, in the database it is different. Presumably you also think Mike and Scott are also both "incompetant" - as they both examined the report and found no action was required.