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:
