On May 16, 2005, at 11:53 AM, Mark Womack wrote:
I figured that a "[VOTE]" message would get folks more interested in
discussing.� :-)� Here is proposal #2.
Assume that we will adequately inform the user base what is going on with
the versions, starting with a detailed email to the user list.
1) Release 1.2.11 with JMS build fix.� Timeframe is immediate, within the
next week.
+1
2) Release a 1.2.12 version with the TRACE change.� I think we should
consider only major bug fixes for inclusion as well, but keep it within
reason.� Timeframe is within a month of the 1.2.11 release.
Specific bugs that have been recommended, but not reviewed are:
31056
17862
23705
24159
26345
26433
30838
31727
33827
TBD: final set of bug fixes to include (Owners: Mark, Curt, ??).� We should
not take more than a week to hash this out.
+1
3) Release a 1.3 version based on the current main branch.� We can discuss
if we want to change the version to 1.5/2.0, but I think we should stick
with 1.3 for now.� Timeframe: release of first final version by 10/2005.
TBD: determine final set of tasks and release target dates (Owner: Mark).
We can work on 1.2.12 and 1.3 in parallel.� There won't be that much overlap
time.
+1
Paul, when you have a chance, would you be willing to do a jDiff report
against the 1.2.x code and the current cvs main?� That might help us in
deciding on what we want to call the next major version, and it will be
useful for the user base to see what has changed.� Maybe we can add it as a
target in the build file?
I think the code review is essential before getting too far in the release cycle.� I'd use it more as a guide to what could be changed to be comfortable with a 1.3 label, than an indicator that a 2.0 label is needed.� I'd also like to see it used for a systematic review of the changes.� There are definitely things in the new API's with which I had qualms with but was unable to engage in constructive discussions at the time.
It may be possible to add JDiff to Gump and add a logging-log4j-jdiff target that would automatically build a JDiff report nightly.
I'll have a look around the gump projects and see how/if JDiff is being used, and hook it up for us.� At the very least I'll have a 1.2.9 vs Head JDiff report that I can distribute to the group, but having an automated one would be a worthy goal as we continue to change.
Clover is a good idea, but lets not rest on it's results.� Clover can give us a guide as where we may like to focus to add test cases, but just because an area of code is covered, does not mean it's covered for all cases.� I like Curt's idea of using the Clover report in conjuction with the JDiff report to allow to focus on risk areas.
