Agree. This will become even more evident when we move past Bloodhound 1.0 Personally I like what Eclipse is doing:
They have planned versions like 4.0, 4.1, 4.2... (new features) once per year (it is a huge project). They release every 6 weeks and that are called milestones: 4.1-M1, 4.1-M2... 4.1-RC, 4.1-Final For us it could be monthly releases (milestones) with maybe 3 planned/road mapped versions per year. But I would not worry about it to much until we reach 1.0 Peter On Mon, Oct 8, 2012 at 7:15 PM, Olemis Lang <[email protected]> wrote: > On 10/8/12, Joachim Dreimann <[email protected]> wrote: > > Hi everyone, > > > > :) > > > I'd like to propose a new release process for releases after 0.2 (once > > accepted). > > > [...] > > > > 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. > > +1 ... at least the idea sounds good to me . Nonetheless we should > figure out some «recovery startegy» because nothing is perfect , and > e.g. minor delays should be tolerated if there's a good reason for it > to happen ... IMO > > > 2. Milestones are for meaningful goals we're working towards. For > example: > > Multi product, Responsive Layout, etc > > IMO the main reason for having milestones is to work towards a due > date and provide value to the project as it evolves (e.g. release , > but maybe not the only goal ;) . What I notice regarding this aspect > you mention is that your milestone will never end , so due date would > be useless even if defined . The reason is that there are always > enhancements , proposals , defects , ... related to features like > those you mention above . Indeed it's possible to work on many tickets > to deliver something at a given time , Release 1 is an example . > > > 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. > > > > There are no meaningful versions defined in the issue tracker afaics . > However my question is ... what is version ticket field for ? AFAICS > there are two options . > > 1. Someone finds a bug or request for an enhancement and specifies > the version considered as a starting point e.g. the version the user > is running on some server out there ... > 2. The target version in which work related to this ticket will be > released > > > Obviously that would make the release frequency very predictable. > > IMO that will result in never-ending milestones . IMO they should > represent project iterations instead . > > [...] > > > > 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. > > > > IMO in practice that will be pretty hard if using your model unless we > are talking of trivial features , of course . > > [...] > > but please provide feedback on whether the plan itself is > > sound, not the possible exceptions. > > > > my $0.02 > > -- > Regards, > > Olemis. > > Blog ES: http://simelo-es.blogspot.com/ > Blog EN: http://simelo-en.blogspot.com/ > > Featured article: >
