On Thu, Jun 5, 2014 at 10:52 AM, Brian LeRoux <b...@brian.io> wrote:
> Pls elaborate on how we can be more efficient?
OK, the following suggestions are offered with no expectations and from
humility as a Cordova noob.
* Avoid "retagging" during the release process. Having the same version tag
mean different RCs at different times destroys history and causes all
sorts of confusion when testing, discussing, voting or performing
post-mortem analysis.
* Be more rigorous with the term "release candidate". Don't call something
a "release candidate" unless it's *immutable* and there's going to be
a *vote* on it.
* Utilize RC numbers to differentiate release candidates. Each time a new
one is created, add a new Git tag in the format `X.Y.Z-rcN`.
* When in doubt, increment the RC number. Skipping RC numbers is minimally
confusing because it is safe to assume that any earlier RC has been
withdrawn and is superseded by the later one.
* Incorporate RC identifiers into VOTE thread subject lines. For instance:
`[VOTE] cordova-firefoxos 4.0.0-rc2`
* Since votes for each platform are held independently, consider isolating
release candidates within your dist/dev area using directory names
incorporating the RC identifier such as
`/dev/cordova/CB-XXXX/cordova-firefoxos-4.0.0-rc2` (which would hold the
files `cordova-firefoxos-4.0.0.zip`, `cordova-firefoxos-4.0.0.zip.asc`,
etc.). The idea is that each RC directory corresponds to one and only one
VOTE thread.
* Only add the final `X.Y.Z` tag when the VOTE passes.
I recognize that implementing these suggestions would require both changes to
Coho and unlearning of ingrained habits. But it seems to me that one reason
the Cordova community finds the release process so taxing is that you're
burdened by a mental model where "release candidates" are mutable.
HTH,
Marvin Humphrey
