During the academic year, the CUNY Academic Commons receives a maintenance release on the second and fourth Tuesday of each month, at approximately 11am Eastern time. Maintenance releases consist of the following:
- Minor updates to WordPress, BuddyPress, and other plugins and themes. A “minor update” is defined as a “dot-dot” release; an upgrade from version 2.3.1 to 2.3.4 is a minor update, while an upgrade from 2.3.1 to 2.4 is not.
- Miscellaneous fixes, as prioritized by the Commons development team. These fixes will generally be discussed on the project’s public bug tracker; see for an at-a-glance view of upcoming releases.
Maintenance releases of the Commons itself are also numbered according to the dot-dot strategy. For example, the upgrade from 1.5 to 1.5.1 was a maintenance release.
Except in emergencies, no code will be deployed to the Commons except for on this twice-monthly release schedule. Members who are interested in new Commons functionality, and particularly those partner developers who host their sites on the Commons, should submit plugin requests and other updates via Redmine at least four days before a given release in order to be considered for that release.
When a scheduled maintenance release falls on a major holiday (for example, December 25, 2018, which is both Christmas Day and the fourth Tuesday of December), the release may be delayed until the next regular business day, at the discretion of the development team.
During the summer months, the development team may revert to a less frequent release schedule. Watch the dev blog for updates.
Major Update Releases
The second maintenance release of each month (on the fourth Tuesday of the month) is designated a “major update release”. In addition to the tasks described above, this release will contain all applicable non-minor releases for WordPress, BuddyPress, and other plugins and themes. These updates are sequestered into a single monthly release in order to give plenty of lead time to Commons partner developers about updates that might affect their site functionality in significant ways. On the 5th of each month, the Commons development team will post an update to this blog with a list of plugins that will see major upgrades on the fourth Tuesday of that month. On that Tuesday, the plugins from that list will be updated to the latest version of the release series announced in the blog post of the 5th. Example:
On September 5, the version of the Events Manager plugin running on the Commons is 5.4.4. The next available version is 5.5.1. The dev blog announces that Events Calendar will be upgraded to 5.5 as part of that month’s major update release. On the fourth tuesday of that month – say, the 24th – the plugin will be upgraded either to 5.5.1, or to any later version in the 5.5.x series that is available as of the 21st. However, if 5.6 is released between the 5th and 24th, the Commons will not receive an upgrade to 5.6.x on the 24th; this major upgrade would wait for next month.
Those members and partners who depend on certain plugins on the Commons and are concerned about upgrades should subscribe to the dev blog RSS feed, and watch for these announcements on the 5th of each month. That’ll give you at least two weeks of lead time before the release to verify functionality of the major upgrade. Alternatively, if you’ve determined that the major upgrade will break your site in a way that cannot be fixed by the fourth Tuesday of that month, you can petition to have the major upgrade delayed; leave a comment in the blog post, or send an email to email@example.com.
Several times per year, the Commons receives a major “feature release”, or “dot release”. For example, 1.5 was a major release. Feature releases contain major new functionality, primarily for the main BuddyPress portion of the site at https://commons.gc.cuny.edu. Feature releases may sometimes also “count as” a maintenance release, containing miscellaneous plugin updates, bug fixes, etc. The timing for these releases is determined ad hoc by the Commons development team. Watch the dev blog for updates.
When the development team and Commons leadership determine that a production bug cannot wait for the next release, it may deploy an emergency “dot-dot-dot” release. For example, 188.8.131.52 was an emergency release.