mike_vbulletin3_import14309
New Member
vBulletin 3.7.1
It is four weeks today since the 'gold' release of vBulletin 3.7.0. In that time, we have been busy squashing the inevitable collection of bugs that get reported after large numbers of customers deploy a new major version to their servers.
We would like to take this opportunity to convey the details of a new release schedule that we will now be rolling out.
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.
Security Flaws and Data-Loss Bugs
As usual, we will any fix security flaws and serious data loss bugs as soon as we become aware of their existence, and will do a release as soon as the fix is implemented and tested.
Wherever possible, this will be done in the form of a Patch Level (PL) release, where only a small number of files are updated and no upgrade script is required, but when this is not possible, a full release will be performed, as was the case with 3.6.10 and 3.7.0 Release Candidate 4.
Notable Changes and Improvements
New Settings
Allow Owners to Delete Social Group if Empty
This option will allow any group owner to delete a Social Group if they are the only member of that group (even if they lack the "Can Delete Own Social Groups" permission)
Thread Tag Banned Words
These words will be checked in addition to those listed in includes/searchwords.php to form a list of words whose use is banned in tagging.
Thread Tag Allowed Words
Words entered here will be allowed as tags, regardless of whether or not their use would be otherwise disallowed due to length, censorship, commonality etc.
Tag Cloud: Build Usergroup
The tag cloud pulls together data from threads in many forums. Users may not be able to see all the threads that make up the tag cloud results. With this option, you can force the tag cloud to be built as if it were viewed by a particular usergroup.
Feature Improvements
Option to control deletion of empty social groups.
Previously, users without permission to delete their own group could always delete the group if no one else was a member of the group. This caused a potential loophole, related to kicking members from the group. There is a new option to control whether owners can delete empty groups without the normal delete group permissions.
Tag delimiter now customizable.
Board administrators can now customer the delimiter used for tagging threads. The comma will still always be used, but this allows administrators to specify a language-specific delimiter (like an Arabic comma) or change to use spaces to separate tags.
Customizable "good words" and "bad words" lists for tags.
Administrators can now specify words that they always want to allow as tags, regardless of commonality or length ("good words"). They can also specifically list words that would be valid tags, but shouldn't be allowed ("bad words"). Be aware that these settings are for exact matches only, not tags that contain particular words.
Tachy Support for Visitor Messages and Picture Comments
Visitor messages and picture comments now fully support the Tachy Goes to Coventry global ignore system.
Upload Memory Improvements
The way file uploads are handled have been re-written in order to reduce memory usage, it is now possible to upload an attachment of several hundred megabytes while only using a few kilobytes of memory. This new method only works when attachments are stored in the filesystem.
Upgrading from Previous Versions
3.7.1 is a maintenance release. We recommend that all customers running prior versions of vBulletin 3.7 upgrade to benefit from bug fixes and stability improvements.
Full instructions for upgrading vBulletin are available here.
PHP and MySQL Requirements
Please note that vBulletin 3.7.x requires at least PHP 4.3.3 and MySQL 4.0.16 or later.
However, we recommend that vBulletin 3.7.x is run on PHP 5.2.6 with APC (or a similar opcode cache) and MySQL 5.0.51 for best performance and stability.
End of Life for PHP 4
The PHP group has announced the end of life for PHP 4. We strongly recommend that customers update their servers to PHP 5.2.6 if they are still running PHP 4. vBulletin 3.7.1 supports PHP 5 without any problems, though you may need to disable strict mode for MySQL, see here on how to enable 'force_sql_mode'.
Note: We will continue to support PHP 4 in the vBulletin 3 series.
Download vBulletin 3.7.1
As usual, vBulletin 3.7.1 is available for all customers with valid, active licenses to download from the vBulletin Members' Area.
It is four weeks today since the 'gold' release of vBulletin 3.7.0. In that time, we have been busy squashing the inevitable collection of bugs that get reported after large numbers of customers deploy a new major version to their servers.
We would like to take this opportunity to convey the details of a new release schedule that we will now be rolling out.
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.
Security Flaws and Data-Loss Bugs
As usual, we will any fix security flaws and serious data loss bugs as soon as we become aware of their existence, and will do a release as soon as the fix is implemented and tested.
Wherever possible, this will be done in the form of a Patch Level (PL) release, where only a small number of files are updated and no upgrade script is required, but when this is not possible, a full release will be performed, as was the case with 3.6.10 and 3.7.0 Release Candidate 4.
Notable Changes and Improvements
New Settings
Allow Owners to Delete Social Group if Empty
This option will allow any group owner to delete a Social Group if they are the only member of that group (even if they lack the "Can Delete Own Social Groups" permission)
Thread Tag Banned Words
These words will be checked in addition to those listed in includes/searchwords.php to form a list of words whose use is banned in tagging.
Thread Tag Allowed Words
Words entered here will be allowed as tags, regardless of whether or not their use would be otherwise disallowed due to length, censorship, commonality etc.
Tag Cloud: Build Usergroup
The tag cloud pulls together data from threads in many forums. Users may not be able to see all the threads that make up the tag cloud results. With this option, you can force the tag cloud to be built as if it were viewed by a particular usergroup.
Feature Improvements
Option to control deletion of empty social groups.
Previously, users without permission to delete their own group could always delete the group if no one else was a member of the group. This caused a potential loophole, related to kicking members from the group. There is a new option to control whether owners can delete empty groups without the normal delete group permissions.
Tag delimiter now customizable.
Board administrators can now customer the delimiter used for tagging threads. The comma will still always be used, but this allows administrators to specify a language-specific delimiter (like an Arabic comma) or change to use spaces to separate tags.
Customizable "good words" and "bad words" lists for tags.
Administrators can now specify words that they always want to allow as tags, regardless of commonality or length ("good words"). They can also specifically list words that would be valid tags, but shouldn't be allowed ("bad words"). Be aware that these settings are for exact matches only, not tags that contain particular words.
Tachy Support for Visitor Messages and Picture Comments
Visitor messages and picture comments now fully support the Tachy Goes to Coventry global ignore system.
Upload Memory Improvements
The way file uploads are handled have been re-written in order to reduce memory usage, it is now possible to upload an attachment of several hundred megabytes while only using a few kilobytes of memory. This new method only works when attachments are stored in the filesystem.
Upgrading from Previous Versions
3.7.1 is a maintenance release. We recommend that all customers running prior versions of vBulletin 3.7 upgrade to benefit from bug fixes and stability improvements.
Full instructions for upgrading vBulletin are available here.
PHP and MySQL Requirements
Please note that vBulletin 3.7.x requires at least PHP 4.3.3 and MySQL 4.0.16 or later.
However, we recommend that vBulletin 3.7.x is run on PHP 5.2.6 with APC (or a similar opcode cache) and MySQL 5.0.51 for best performance and stability.
End of Life for PHP 4
The PHP group has announced the end of life for PHP 4. We strongly recommend that customers update their servers to PHP 5.2.6 if they are still running PHP 4. vBulletin 3.7.1 supports PHP 5 without any problems, though you may need to disable strict mode for MySQL, see here on how to enable 'force_sql_mode'.
Note: We will continue to support PHP 4 in the vBulletin 3 series.
Download vBulletin 3.7.1
As usual, vBulletin 3.7.1 is available for all customers with valid, active licenses to download from the vBulletin Members' Area.
