Release Automation ------------------ The eventual goal is to automate fully the production of packages through Hudson (missing the chaining of jobs). To achieve this, the dependencies between the various packages need to be explicitly given. Maintainers for each package should provide this information. ACTION: Package maintainers should provide dependency information for their software. In the longer term, it would be better to produce the release before the demo meeting and use that pre-release for the actual demo. However, in the short term this doesn't seem realistic, so the idea is to generate the release packages just after the demo meeting. This introduces a slight risk that the released packages might have unforeseen problems. As we get more proficient at the releases, we may move to staged releases which are explicitly tested in the demo. DECISION: Release packages will be generated after the demo meeting through hudson. It is easier with maven/hudson to create a complete set of new packages for every release. This means that each package's version number will be incremented, even if there are no actual changes in the code for that package. Making the release production simpler was viewed as a reasonable trade-off for the larger number of packages produced (and any possible confusion). DECISION: Each release will contain a complete set of newly versioned packages. Release Policy -------------- A public release for every sprint (~3 weeks) was judged to be too frequent and too costly for support. A compromise was to have a public release every other sprint (~6 weeks). However, every sprint should still result in a definite set of packages that are validated at the demo meeting. DECISION: Provide a public release every other sprint (~6 weeks). Package maintainers should strive to meet all of the following requirements for their software: * Integration in the manual installation. * Integration in the Quattor installation. * Documentation of configuration and deployment scenarios. * Hudson job for testing code and creating packages. * Hudson job for generation of release packages. * Integration in user/administrator tutorials. In the short term, these requirements will be applied with some discretion. In the longer term, they will be hard requirements for the developers/integrators. There will be an overall "changelog" and "release notes" documents. Corresponding documents should be provided for all components of the release to facilitate the generation of the overall documents. ACTION: All package maintainers must provide "changelog" and "release notes" documents for their software. This should include "high-level" changes in the software and not be a list of commit messages. These should be updated for each sprint. ACTION: The person building the overall release will combine the "changelog" and "release notes" documents for each package into an overall document for the public releases. Support and Deployment Policies ------------------------------- The discussion highlighted that there are different needs for the various infrastructures that StratusLab provides and that the deployment frequency of the releases may be different for each type one. Test infrastructures: Should have the latest development release installed along with any recent development packages. This allows people within the project to test the deployment and functionality of their software. Reference/Preproduction infrastructures: Should have the latest public release deployed. People using these infrastructures should understand that their main purpose is to provide rapid feedback on the current version of the software and should be more tolerent of downtimes associated with these upgrades. Production infrastuctures: Should be upgraded only when the new features/bug fixes warrant having a new release deployed. This will be a tradeoff between deployment effort (and downtimes) and benefits for end users. DECISION: Upgrade non-production infrastructures with each release (or more frequently). Upgrade production infrastructure when new features/bugfixes make the effort worth the disruption. This means that the project will support the latest development release and the release that is installed on the production infrastructure. Support for other releases will only be provided with minimal effort and the response might be "to upgrade to latest release." DECISION: Support only last development release and the release installed on the production infrastructure. Release/Sprint Numbering ------------------------ If possible, the sprint and release numbering should be identical (e.g. 0.1.0 is production, 0.1.1 is development). If this cannot be done reasonably, then separate numbering should be used. Final decision should remain with WP4.