Hi Wayne,
Sorry for the late reply :(
On 13/03/14 18:35, Wayne Beaton wrote:
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?
The way we normally release in Vert.x is we have all our features
and bugs in the issue tracker (now Bugzilla), we prioritise them,
and work on them. Then, every 4-6 weeks we simply release whatever
we have ready, so there's no real upfront plan or any special
significance for any release , and don't really know what
features/bugs are going to go into each release up front as
priorities may change during the cycle. Basically each release is
timeboxed.
I think it's important to note that these rolling 4-6 releases are
not milestone releases (as that implies they are somehow leading up
to as "big" release") - they are not, each release is just as much a
release as any other and has undergone the exact same level of QA.
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
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
|