Misunderstanding developer previews versus release candidates

[Richard Gaskin]

Thanks for that background, Kevin.

It certainly does make good sense to have more than one development 
track going on, and indeed it's been a great thing for all of us.

My issue wasn't with having multiple tracks, but only with the much 
smaller issue of when the "DP"/"RC" label changes.

If a given build is anticipated to have a much longer cycle, it raises 
the likelihood that it may still incorporate more significant changes 
than one which is closer to release.

So I strongly support your team's multi-track efforts, and the effect on 
quick rollout have been tremendous.

It's just helpful to communicate anticipated cycle length by sticking 
with "DP" as long as possible, changing to "RC" only when it's truly a 
candidate for release.

This helps devs better anticipate feature and bug-fix sequencing, and 
helps avoid tester fatigue by more clearly communicating where they 
should focus their efforts if they're pressed for time.


Kevin Miller wrote:

> Our release process is simple and pragmatic.
>
> The main difference between DP and RC is that by-en-large DPs are not
> feature complete, RCs are. As such DPs may have half finished features or
> have several features planned in the cycle missing. We are very reluctant
> to add features to RCs and will do so only if it is a minor addition of
> something low risk but very high value or urgent. Clearly a release that
> is not feature complete (DP) is not going to be released. An RC is turned
> into a release when the number of bugs reported against its falls below
> the level required by internal criteria.
>
> There is no reason that there should be more or less of one or the other.
> We could have one DP to get all the features in a given version we plan
> then take some considerable time to get it stable. The number of each is a
> function of how many features we need to add or how many bug reports we
> get back (and various new criteria that are being created as we add to the
> breadth of tests in our new internal automated test framework). Larger
> point release upgrades are far more likely to have more of one or both DP
> and RC.
>
> The purpose of having two cycles going at once is in direct response to
> customer demand! It is an innovation, a benefit created by our increased
> engineering capacity. Those commercial customers with complex shipping
> software are slower typically to jump from a 6.1 to a 6.5 or a 7,
> preferring to align such a shift with a new project or major upgrade of
> their own software. Creating an additional release with bug fixes in it
> helps us serve those needs better. History suggests that a x.x.x release
> will take far fewer RCs than a x.x release so the chances are that this
> will allow us to bring those fixes out faster.
>
> We have a lot of releases coming up over the next few months, the natural
> result of all the re-architecting we've been doing. Hopefully the
> explanation above helps to straighten things out as we enter this busy
> period.
>
> Kind regards,
>
> Kevin

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys