incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: [Proposal] New release process
Date Tue, 09 Oct 2012 04:56:33 GMT
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 <olemis@gmail.com> wrote:

> On 10/8/12, Joachim Dreimann <joachim.dreimann@wandisco.com> 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:
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message