I appreciate your input.
Is it reasonable to expect a short description, list of new
features, new and noteworthy, or some equivalent for every release
on a four-to-six-week cycle?
We've narrowed in on four-to-six-weeks. Is this really what we mean,
or is it more of a "release when we feel it's right" sort of vibe
we're looking for?
More comments in line.
On 03/13/2014 12:06 PM, Joakim Erdfelt
wrote:
In my mind "critical bug fix" falls quite comfortably into the
"bugfix work" category :-)
Strictly speaking, in the current process new features or API
changes would have to be captured (at least in coarse terms) in the
review documentation. We could probably get away with minor API
changes occurring during a review period.
Frankly, this sounds like a plan theme to me.
Actually, you don't know what I'm thinking :-)
But are these iterations producing "releases" or milestones?
Technical previews? I think that this might be a different--but
still useful--example. I would expect that anything I'd downloaded
based on an evolving specification is pre-release or technical
preview, not an official release.
I disagree with this in the context of your example. It would be
perfectly reasonable to make a plan item along the lines of
"implement the current version of the spec" (maybe a little wordier
than that) and then zero in on a particular version of the spec when
you decide it's time to actually push out a release. At some point
you have to put some stake in the ground. At that point, you update
the plan to reflect that decision.
Again, though, I think that this is a different case. I think that
this case is more about deciding how to deal with a "technical
preview".
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
|