Daniel John Debrunner wrote:
Rick Hillegas wrote:
I have checked in a fix (DERBY-1886) which removes junit.jar from the
source distributions. I'd rather not spin a new release candidate.
Instead, I was hoping that the following would be adequate:
1) Hand-remove junit.jar from the source distributions for 10.2.1.5.
2) Re-sign those distributions.
Does this sound adequate?
-0
It may be ok in this case but it is not a good example to set. This
means the release is inconsistent, which can be viewed in two ways:
- the source code within the release would not reproduce the same
binaries as in the release
- picking up the code from svn directly using the svn revision
number in the release will not lead to the same binaries.
Is the problem with re-building the releases that it takes a long time
or includes a number of steps that are not automated? I thought from
previous releases the release signing seemed to be the most
problematic part, which needs to be done in this case anyway. If there
are problems with building a release then are there Jira entries for
addressing them?
Thanks,
Dan.
Hi Dan,
Re-generating the release candidate isn't that hard. There are a lot of
steps in the process but once you've done this half a dozen times, it's
pretty easy. I can re-spin a 10.2.1.6 release candidate in a couple
hours. In my mind, a complete re-spin would be a signal to people to
re-start their test cycles. I'm reluctant to interrupt that testing
particularly because I'm not convinced that we've found the last
structural problem with the release candidate--as of yesterday
afternoon, the structure of the core eclipse plugin was still in motion.
If the structural issues stay settled for a couple days, I could
regenerate a 10.2.1.6 candidate and initiate a new vote. Do you think I
should do that?
Regards,
-Rick
