Hi everyone, I'd like to propose a new release process for releases after 0.2 (once accepted).
Our current process (as I understand it): - A milestone containing tickets we believe should be fixed for the release is created. - Someone volunteers as release manager at an arbitrary point and packages up a release ready to be voted on. - All uncompleted tickets in the milestone are moved to the next upcoming milestone. In my opinion this is a messy process in which releases are unpredictable in scope and frequency. Proposed new process: 1. Monthly release cycle with the packages ready to be voted on during the first full week of the month. 2. Milestones are for meaningful goals we're working towards. For example: Multi product, Responsive Layout, etc 3. Versions are set up reflecting the priority Milestones for the next release. When the release is being packaged up, all tickets fixed since the last release are assigned to the Version. Obviously that would make the release frequency very predictable. I believe it also better reflects our actual working practice in the project better and make it easier for new contributors to pick up tickets. Meaningful Milestones allow us to track how we're progressing towards goals such as Multi Product or a Responsive Layout over several versions. Versions would clearly reflect what has been covered in each release, and bugs can be raised against them. Longer term, with more contributors, we may get to a point where we're able to complete one or more whole milestones within each release cycle. I'm sure we will come across situations where we need to make exceptions to this process, but please provide feedback on whether the plan itself is sound, not the possible exceptions. Cheers, Joe
