: > *IMMEDIATELY* ...
: > 1) rename "4.0" to "4.0-BETA" in jira and mark it released
: > 2) add a new "4.0"
: >
:
: One challenge with that is the fact that development will still be ongoing.
: So i propose we rename it to 4.0-BETA the day we cut the first RC, but
: dont yet mark it released.
yeah, sorry -- that's totally fine -- my "immediate" comment was
really just about the rename and adding the new version -- when it gets
marked 'released' is really less of a concern.
: CHANGES is easier to manage than JIRA, so I think that *when we create
: a release candidate* for 4.0-BETA,
: we should just add the 4.0-FINAL section already.
...
right -- and more importantly: it's easy to manually deal with
active/recent issues during the days arround the release (either in
CHANGES or in Jira) then it is to deal with the 100+ isues that have been
resolved for a while and may already have multiple fix versions that we
don't want to blow away in a bulk edit.
Bottom line: adding "4.0-ALPHA" as a completley new version was what bit
us hard this time. in situations like this we should error on the side of
renaming the version ASAP and adding a new one for the unreleased stuff to
start using. Even if we have a long drawn out RC vote with multiple
re-spins, it's trivial to "merge" versions in Jira ... it's hard to
"split" versions and say "these were before RC7 so they made it into
the BETA, but these were after RC7 so they should be listed in the
FINAL"
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
