[Neos] [Team] Procedure for setting target version

[Ernesto Baschny [cron IT]]

Hi Robert,

having just posted something about that for TYPO3 CMS the last days [1],
I would like to you take a look at it.

Basically our experience with working with a workflow you mention below
has been:

a) if you let everyone to set "Target versions" you (the release team)
are constantly battling against randomly set target versions. There is
no way in the issue list to differentiate issues which *you* assigned a
target to or which "some random other" has assigned to. The list gets
bigger, the job harder as you go over the same issues over and over again.

b) most pending issues in the tracker are either bugs *or* suggestions
from external parties (at least in TYPO3 CMS). Setting a "target
version" on those makes no sense at all, as we depend on volunteers to
actually work on these tasks. The friendly helpers end up constantly
updating the target versions, for example as in [2].

c) maintaining target version manually after actually releasing a
package you inevitable get "out of sync" due to human errors. This
information is redundant anyway (the changelog can be generated from the
commit log), noone wants to voluntarily maintain it manually - damned to
fail.

d) most basic: there cannot be "Multiple Target Versions" which would
allow Redmine to put the same issue into multiple roadmaps / changelogs,
important for backported bug fixes (which we do a *lot* in CMS). Maybe
Redmine could be modified to do so (probably would require some plugin /
Ruby development... - who would do that?).

On the other hand we already have our "merged into branches" script
which actually shows what was included in which branch (and also which
backports are pending). This is an information which I could imagine to
be displayed in the Forge Issue, maybe as an "REST widget" somewhere
above the related commits. As soon as we have the "released into branch"
working on "tools.typo3.org" we could try to do that.

So basically my suggestion (at least for TYPO3 CMS) is to get rid of all
"patch-level-target-versions" and just hold on a generic branch-less
"next-patchlevel". For planning next major versions the release team can
set a "6.2" generic target version, or (optionally) split up the next
version into different roadmaps ("6.2 Performance", "6.2 FAL", ...etc)
to be able to visualize the status of the work on these areas separately.

Then we could set up a pretty simple rule: Noone except the release team
should set *any* target version. The only field the reporter or a
friendly issue updater could set is the "TYPO3 Version" which specifies
which oldest stable branch the issue applies to (so that we can sort out
"old bugs" from "new bugs").

Actually "some" inspiration (at least in the "next patchlevel" version)
came to me from Redmine's own Roadmap [3]. Here you see "Candidate for
next major release" and "Candidate for next minor release".

What do you think?

Regards,
Ernesto

[1] http://forum.typo3.org/index.php/t/196874/
[2] http://forge.typo3.org/issues/24317
[3] http://www.redmine.org/projects/redmine/roadmap


Robert Lemke schrieb am 21.05.2013 13:53:

> as I just was going through all (well most ...) of the open Flow issues,
> I remembered that we still need a plan for when to set the target
> version and to which version. So, here's what I'm currently doing and
> what I suggest for the future:
> 
> - all new issues should have _no_ target version set unless they have
> been screened by a team member.
> 
> - if an issue should go into a certain branch, a team member selects the
> version of the next release for that branch (for example "2.0.0")
> 
> - if you want to finally release a branch you can also decide to
> postpone a non-critical bug fixes to the next patch level version
> (trying to release "2.0.0", so postpone the bug issue to "2.0.1")
> 
> - you cannot target features to patch level releases (2.0.1, 2.0.2, ...)
> 
> - if a feature should go into some future version which is not being
> worked on yet, you set it to the generic branch version, for example
> "2.x" and "3.x"
> 
> - when planning the next version, the release manager + team goes
> through issues from "2.x" and sets versions to the actual version, for
> example "2.2"
> 
> In general any team member can help setting target versions, but the
> release manager of a version should keep an overview of what goes into
> his release.
> 
> Certainly missed some points, but just posted this as a reminder (for
> myself).