bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [Proposal] New release process
Date Mon, 08 Oct 2012 17:15:33 GMT
On 10/8/12, Joachim Dreimann <> 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



Blog ES:
Blog EN:

Featured article:

View raw message