- Release official updates every two months (ish).
- Aim to split the release schedule in two phases, the first “development phase” for fixes and new features, the second “testing phase” for only testing and bug fixing.
- Declare a “Feature Freeze” for the scope of the first “development phase”, so that everyone knows what is being done for the next version, no need to guess or get unexpected changes (I reserve the right to slip in good ideas, especially if quick to do so!).
- During the “development phase”, to always provide a download version that mirrors the code running on the WPS site. This allows users with specific reasons to get the latest version.
- Once a version of the code includes all new features scoped out and has undergone local testing, it will be “locked” and only bug fixes will be applied from then on, no new features will be added – ie. the start of the second “testing phase”.
- Only when the second “testing phase” has been satisfactorily completed, will the official release be made.
- Which “phase” is currently active, will be displayed in the release notes (link via home page).
This would mean that:
- this gives me at approximately four weeks to add new functionality (“development phase”), and then dedicated time to test and re-act to any others who are testing/using the release candidate (“testing phase”).
- gives those who want to install and/or test the latest version of the code, the ability to do so, with all latest features and changes.
- with sufficient information in the release notes that are combined with an official release, updates can be skipped if not considered necessary by site admins.
As a sort of disclaimer, although I would love to make WPS compatible with every other WordPress theme and plugin, realistically this is tough, as it depends on the 3rd party theme/plugin and there are some shockingly bad examples out there (and some superbly good ones too!). Therefore, unless an issue is generally effecting compatibility with multiple themes/plugins, these would not hold up the release schedule.
Finally, I would stress that releases would only be made if there are no serious outstanding bugs to resolve. With over 100,000 downloads of WPS, there are now enough users of WP Symposium out there to take this schedule and release management seriously.
The version number will reflect the anticipated month of release followed by either NB (for nightly build during development phase) or RC (for release candidate when in testing phase).
As a final note, I can assure you that my dedication to WP Symposium has never been higher. It started in December 2010 as a spark of an idea, I’ve experienced several learning curves and I have met (virtually!) some fantastic people, who I continue to be humbled by. I also continue to learn almost everyday and truly believe that WP Symposium can continue to grow (and stabalise!) in ways as yet even to be realised.
And as another final note… many other products where mentioned on this website have died off. I know a few of their developers, and the same thing caused their demise – the stress and time in providing support. Please be nice, we try our best! ;)
Thanks for reading,