My preference would be 2 to 4 :-) In 2001, I was in a position to effectively dictate that speed for Subversion. It was a huge win for the nascent community.
Cheers, -g On Oct 9, 2012 1:49 AM, "Peter Koželj" <[email protected]> wrote: > 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 > > >
