Actually I was not trying to propose Eclipse scheme for pre 1.0 releases. I think what we have right now is good enough until then.
All we need is higher frequency, anything between 4 and 6 weeks sounds reasonable. Peter On Tue, Oct 9, 2012 at 9:21 AM, Greg Stein <[email protected]> wrote: > Too much process. Just make a release every N weeks. If something is done, > then it gets in. If not, then maybe it gets in the next release. Don't be > afraid to ship bugs because they will be fixed in two weeks in the next > release. This is not 1.0 -- there is no need to treat it with kid gloves. > Beat it up. If the release is total crap, then turn the crank and release > again a few days later. > > Don't get so hung up on what is in/out. Just make releases. Continually and > repeatably. > > The goal is activity, to build community. > > There should be (IMO) goals about features at this point in time. > > I disagree with the Eclipse numbering before 1.0. The project is not yet > managing feature releases. 0.2 then 0.3 ... Version numbers are cheap. Use > them. > > Cheers, > -g > On Oct 8, 2012 5:16 AM, "Joachim Dreimann" <[email protected]> > wrote: > > > 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 >
