I also vote
a) -0 b) -1 c) +1
since 4.0 has lots of other breaking changes (removing deprecated APIs in
particular) requiring some import reorganizations isn't a big deal in my
opinion, and doesn't block the advancement toward supporting future Java
versions.
I'd rather not need to publish an additional JAR file and document which
one was needed for what contexts/purposes, and all the questions coming
from people not RTFM or JFGI.
Leaving things as-is doesn't hurt me in the next couple of years, but as
always, the longer one takes to migrate to the latest, the more pain is
involved when the time comes due.
On Mon, May 21, 2018 at 3:17 AM Andreas Beeker wrote:
> Hi,
>
> We had a few arguments on #62355, but no decision and I don't want it to
> peter out.
>
> Would you mind, if we have a vote?
>
> a) leave it as-is - the classes stay in the java packages
>
> b) provide an additional one-big-jar
>
> c) apply the patch
>
> FYI - there might be more changes necessary for the automatic modules to
> work,
> but in my use case (POI-Visualizer) I didn't receive any more errors.
>
> Here is my vote: a) -0 b) -1 c) +1
>
> Of course I'm open for further discussions on b)
>
> Please have a look at code modifications votings before you vote:
> https://www.apache.org/foundation/voting.html
>
> Andi
>
>
