The purpose of this section is to highlight the process for future code releases, so that developers are aware of a means by which they can submit code and expect to find their fixes in the next official release of the code. As the product is adopted by local authorities it is important to have a mechanism by which software bugs and minor improvements can be made to the product in a way that, (a) allows developers to make amendments and (b) that ensures that any new release version is robust.
As the product was delivered as a complete web content management system, any further work on the product needs to be minor and should focus on bug fixing and minor maintenance issues. The focus, therefore, is on ensuring stability. No major amendments, therefore, are envisaged as part on an ongoing LAWs Rollout Programme. If the APLAWS User Group as a whole identifies and pays for any enhancements, then it is feasible that these could be built it – on the assumption that any work of this nature will have its own quality assurance procedure.
This document details a framework that can ensure that work towards an ever more stable release is undertaken with rigour. As this is an open source project, it is important to ensure that confidence remains in the product and that fixes to the core release of the code area made is in a methodical way.
The original APLAWS product was delivered from the ODPM’s APLAWS Pathfinder Project and was adopted by several UK local authorities. Following the attention the product received several private sector companies are offering services around the product, including bug-fixing and general maintenance. Several organisations now offer support to local authorities on the product.
It is possible, due to the nature of open source, for several organisations to fork the code so that there are several versions of the code. While this is quite permissible – in terms of the open source ethos – at the same time it makes sense to ensure that there is a main core APLAWS release, so that authorities are aware that the most rigorous version is the one available under the APLAWS banner – i.e. the version available from the project website. This means there is a single official release.
Users of the system would expect the core code releases to be stable and reliable. This, however, implies a robust quality assurance process. Since several organisations are likely to take the development of the product forward, this process needs to be undertaken by those most involved in using the system (i.e. the APLAWS User Group) and in terms of a clear quality assurance process.
The purpose of the framework is to provide a clearly defined process for code release and versioning of the APLAWS+ CMS.
It is essential that developers have clearly defined criteria for submitting code fixes. A first version of this document is available.
Code submissions will be submitted to the APLAWS user Group via the Sourceforge website or an alternative method decided by the user group.
Periodically the submissions will be considered for a new release of the code. This will take the form of a Quality Assurance Team assessing the changes and considering whether they should be rolled into the code or not. This will be primarily based on the principles of stability and value for money for the local authorities. The assessment and priorities will need to be approved by the Quality Assurance Team before any work is undertaken. If submissions are not going to be included, either for quality or budgetary constraints, the developers who have submitted code will be notified of the decision, together with an explanation. A development unit (likely a private sector company) will be tasked with rolling in the approved changes.
One of the aspects that worked well in the LAWs CMS Work Strand work was having an independent Quality Assurance Team to that of the core developers. This principle will continue on the continued release process.
A development unit will be tasked of rolling the approved changes into a new release of the code. This will include preparing release notes of what is being changed and will need to include regression testing. The delivery will need to be a robust new beta version of the code.
The Quality Assurance Team will be required to package the code and sign off that beta testing has been completed. A beta version of the code will then be released.
The development company will be required, for a period of two weeks, produce a bug-logging environment (e.g. Bugzilla) and take bugs directly linked to the new changes. Any bugs picked up that are new – i.e. not connected to the new build will need to be logged and submitted to the Quality Assurance Team, who will need to confirm that these are new bugs
Following the bug-fixing fixing process the Quality Assurance Team will be required to package the code and sign off that bugs have been eliminated. A new release of the code will then be made. Release notes will be provided with the new code.
The attempt will be to have clearly defined periods by which the release framework is undertaken. This gives vendors a clear indication as to when they should submit code
It also give local authorities a clear idea of when they should expect to see a further stable release of the code. This allows (see diagram) for dissemination and user groups to occur in-between these releases.
Due to the complexity of organising this process it is envisaged, therefore, that there will be only three further releases of the period before 31 March 2005, those being
30 June 2000
31 October 2004
28 February 2005