Posted by Simon Goodchild  at September 6th, 2012

Thank you to all who have contributed to this topic both on the forum and via other means (email, etc). I am certainly taking on board everything that has been mentioned, especially the issue of stability, and therefore implementing the following release schedule.

• Release official updates less often (proposing to aim for monthly, but longer if necessary, see below), weekly is too rapid, causing too many headaches. Less haste, more speed, and all that.
• 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.
• During the “development phase”, to always provide a download version that mirrors the code running on the WPS site, to be renamed as the “nightly build” or “NB”  (the “use at your own risk” version). 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 readily displayed at the top of the WPS website.

This would mean that:

1. this gives me at least two 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”).
2. gives those who want to install and/or test the latest version of the code, the ability to do so via the nightly builds, with all latest features and changes.
3. 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.

Finally, I would stress that releases would only be made if there are no serious outstanding bugs to resolve.  With 2,000+ installations of the latest version, 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). On that basis, as at the time of posting this, I have made available v12.10 NB1 as a download. The Welcome Page within the installation includes changes made. Note that if the release month becomes November, for example, then the version will change to v12.11 at some point.

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 were 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,
Simon