I wanted to give some advance notice
of an issue with the 202 build -- to be discussed at this afternoon's status
meeting.
Yesterday I discovered a I made a mistake
in the final 202 build for our download site. The changes I had been making
to sign jars for 3.0 stream "leaked" over into the final 2.0.2
build. See bug (bug
221450).
While signed jars should not cause any
functional difference, there is a risk of subtle performance issues and
is a larger change than we'd normally want to make in a maintenance release.
Given the order of events, the jars
on update sight are not signed, the jars in the EPP package are not signed
(they are pulled from update site) .... only the jars in the final zip
for the "R" build got signed.
So ... what to do? I see the options
are:
A. Do nothing. Assume the best --
that there are no huge problems with signed jars, and installing from update
site or EPP Package will dominate and/or provide a work around if issues
found.
B. Respin a 202B that is just like 202
but with the signing flag correctly turned off. And simply replace the
current 202 R build with this 202B R build. In this re-build, all
the jars will have the exact same version numbers as the 202 build. If
we do this one, we should also re-smoke-test that final 202B build just
as a sanity check, so it is more work.
I think this is mostly driven by "what
do adopters want" -- do adopters rely on our zips, or our update site
jars? Do signed jars concern them? So will look forward to suggestions.
While not much notice, I'm hoping this
note will lead to a decision at status meeting. If more time is needed,
that's fine ... just wanted to make people aware and get the discussion
started.