My opinion is that it is not correct to release with a new dependency that brings 120+ deprecation warnings. At the same time, I'm very reluctant to rewrite all getXXXArray() to getXXXList() just to keep javac quiet. I wonder if it is possible to suppress them and build ooxml-schemas-1.1.jar with JDK 1.5 support AND getXXXArray() being not deprecated. Perhaps XmlBeans 2.4 does a better job.

The purpose of switching to ooxml-schemas-1.1.jar is to use shorter and nicer code. Instead we just switch jars and get tons of warnings.

I see two paths to follow:

 (a) revert to ooxml-schemas-1.0.jar and re-cut release. I'm +1 in advance.
(b) abort the vote, test-drive ooxml-schemas-1.1.jar for a month or so and cut release in July.

Current combination of old code and new new jar does not work for me.

Yegor

On Mon, 14 Jun 2010, Yegor Kozlov wrote:
I propose to revert trunk and REL_3_7_BETA1 to use ooxml-schemas-1.0.jar (JDK 1.4). There is only one or two classes using JDK 1.5 features and it should be easy. Then re-cut release and only after it change trunk to use ooxml-schemas-1.1.jar. This way it will be safe.

That would mean that we wouldn't get any feedback from the beta about how well the JDK 1.5 version (ooxml-schemas-1.1) performs though. It is a beta, so I'm personally happy to have something in there that ought to work but might break in odd situations (I've inadvertantly been testing the 1.1 jar for ages without issue, and I'm probably no the only one!)

I'll also promise to RM another beta release in a month, or sooner if we discover a big snag! Is that likely to be enough for people, or is there a view that we should keep things very stable here, and potentially have the next beta be less stable?

Nick

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]




---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to