Apache POI 4.0/Java 8

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Apache POI 4.0/Java 8

Dominik Stadler
Hi,

FYI, as 3.17 is out and we agreed to work on 4.0/Java 8 now, I have done a
bunch of changes locally which switch to Java 8 and 4.0 and also use some
newer third party libs. I would like to do some more local testing on it
and then commit it tomorrow.

Just FYI so we don't duplicate efforts here.

Dominik.
Reply | Threaded
Open this post in threaded view
|

RE: Apache POI 4.0/Java 8

Allison, Timothy B.
Thank you, Dominik!!!

So, speaking of 4.0...should we move to semantic versioning: 4.0.0?

-----Original Message-----
From: Dominik Stadler [mailto:[hidden email]]
Sent: Thursday, September 14, 2017 1:39 PM
To: POI Developers List <[hidden email]>
Subject: Apache POI 4.0/Java 8

Hi,

FYI, as 3.17 is out and we agreed to work on 4.0/Java 8 now, I have done a bunch of changes locally which switch to Java 8 and 4.0 and also use some newer third party libs. I would like to do some more local testing on it and then commit it tomorrow.

Just FYI so we don't duplicate efforts here.

Dominik.

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

Reply | Threaded
Open this post in threaded view
|

RE: Apache POI 4.0/Java 8

Murphy, Mark
I think that would be a good idea.

-----Original Message-----
From: Allison, Timothy B. [mailto:[hidden email]]
Sent: Friday, September 15, 2017 7:07 AM
To: POI Developers List <[hidden email]>
Subject: RE: Apache POI 4.0/Java 8

Thank you, Dominik!!!

So, speaking of 4.0...should we move to semantic versioning: 4.0.0?

-----Original Message-----
From: Dominik Stadler [mailto:[hidden email]]
Sent: Thursday, September 14, 2017 1:39 PM
To: POI Developers List <[hidden email]>
Subject: Apache POI 4.0/Java 8

Hi,

FYI, as 3.17 is out and we agreed to work on 4.0/Java 8 now, I have done a bunch of changes locally which switch to Java 8 and 4.0 and also use some newer third party libs. I would like to do some more local testing on it and then commit it tomorrow.

Just FYI so we don't duplicate efforts here.

Dominik.
B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[
�]�][��X��ܚX�P�K�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
�]�Z[�K�\X�K�ܙ�B�B

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

Reply | Threaded
Open this post in threaded view
|

RE: Apache POI 4.0/Java 8

Murphy, Mark
In reply to this post by Allison, Timothy B.
Here is a somewhat radical idea, and maybe too hard to implement, but maybe we should package this a bit differently like poi-core, poi-ss, poi-wp, poi-misc. And then apply semantic versioning to each package separately so poi-core and poi-ss would be at 4.0.0 and poi-wp and poi-misc might still be at 0.4.0 as they are still experimental. I know that the binary formats are ahead of the xml formats in the wp world, so maybe this would still need to be thought out. I wouldn't want too many packages.

-----Original Message-----
From: Allison, Timothy B. [mailto:[hidden email]]
Sent: Friday, September 15, 2017 7:07 AM
To: POI Developers List <[hidden email]>
Subject: RE: Apache POI 4.0/Java 8

Thank you, Dominik!!!

So, speaking of 4.0...should we move to semantic versioning: 4.0.0?

-----Original Message-----
From: Dominik Stadler [mailto:[hidden email]]
Sent: Thursday, September 14, 2017 1:39 PM
To: POI Developers List <[hidden email]>
Subject: Apache POI 4.0/Java 8

Hi,

FYI, as 3.17 is out and we agreed to work on 4.0/Java 8 now, I have done a bunch of changes locally which switch to Java 8 and 4.0 and also use some newer third party libs. I would like to do some more local testing on it and then commit it tomorrow.

Just FYI so we don't duplicate efforts here.

Dominik.
B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[
�]�][��X��ܚX�P�K�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[XZ[
�]�Z[�K�\X�K�ܙ�B�B

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

Reply | Threaded
Open this post in threaded view
|

RE: Apache POI 4.0/Java 8

kiwiwings
FYI - a while back we had already a discussion about format specific
packaging:
http://apache-poi.1045710.n5.nabble.com/Switch-to-maven-td5722213.html

Andi



--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html

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

Reply | Threaded
Open this post in threaded view
|

RE: Apache POI 4.0/Java 8

Javen O'Neal-2
In reply to this post by Allison, Timothy B.
Yes, and our @deprecated messages should be using the new semantic
versioning 4.0.0.

On Sep 15, 2017 4:06 AM, "Allison, Timothy B." <[hidden email]> wrote:

Thank you, Dominik!!!

So, speaking of 4.0...should we move to semantic versioning: 4.0.0?

-----Original Message-----
From: Dominik Stadler [mailto:[hidden email]]
Sent: Thursday, September 14, 2017 1:39 PM
To: POI Developers List <[hidden email]>
Subject: Apache POI 4.0/Java 8

Hi,

FYI, as 3.17 is out and we agreed to work on 4.0/Java 8 now, I have done a
bunch of changes locally which switch to Java 8 and 4.0 and also use some
newer third party libs. I would like to do some more local testing on it
and then commit it tomorrow.

Just FYI so we don't duplicate efforts here.

Dominik.
Reply | Threaded
Open this post in threaded view
|

Re: Apache POI 4.0/Java 8

Dominik Stadler
Hi,

I did most of my changes to switch to Java 8 and adjusted the Jenkins jobs
accordingly. Version is currently at 4.0-beta1, I'll change this to
4.0.0-beta1 soon if nobody beats me to it.

I also pushed a number of automatic code-fixes suggested by IntelliJ which
should make the code-base a bit cleaner, let me know if you spot anything
that seems to go wrong now (hopefully there isn't, but who knows).

Dominik.

On Sat, Sep 16, 2017 at 1:44 AM, Javen O'Neal <[hidden email]> wrote:

> Yes, and our @deprecated messages should be using the new semantic
> versioning 4.0.0.
>
> On Sep 15, 2017 4:06 AM, "Allison, Timothy B." <[hidden email]> wrote:
>
> Thank you, Dominik!!!
>
> So, speaking of 4.0...should we move to semantic versioning: 4.0.0?
>
> -----Original Message-----
> From: Dominik Stadler [mailto:[hidden email]]
> Sent: Thursday, September 14, 2017 1:39 PM
> To: POI Developers List <[hidden email]>
> Subject: Apache POI 4.0/Java 8
>
> Hi,
>
> FYI, as 3.17 is out and we agreed to work on 4.0/Java 8 now, I have done a
> bunch of changes locally which switch to Java 8 and 4.0 and also use some
> newer third party libs. I would like to do some more local testing on it
> and then commit it tomorrow.
>
> Just FYI so we don't duplicate efforts here.
>
> Dominik.
>
Reply | Threaded
Open this post in threaded view
|

Re: Apache POI 4.0/Java 8

kiwiwings
Please use 4.0.0-SNAPSHOT ... I wouldn't use the term beta anymore, so betas become patch versions 4.0.x

Andi

On 9/16/17 5:40 PM, Dominik Stadler wrote:
Hi,

I did most of my changes to switch to Java 8 and adjusted the Jenkins jobs
accordingly. Version is currently at 4.0-beta1, I'll change this to
4.0.0-beta1 soon if nobody beats me to it.

I also pushed a number of automatic code-fixes suggested by IntelliJ which
should make the code-base a bit cleaner, let me know if you spot anything
that seems to go wrong now (hopefully there isn't, but who knows).

Dominik.

On Sat, Sep 16, 2017 at 1:44 AM, Javen O'Neal [hidden email] wrote:

Yes, and our @deprecated messages should be using the new semantic
versioning 4.0.0.

On Sep 15, 2017 4:06 AM, "Allison, Timothy B." [hidden email] wrote:

Thank you, Dominik!!!

So, speaking of 4.0...should we move to semantic versioning: 4.0.0?

-----Original Message-----
From: Dominik Stadler [[hidden email]]
Sent: Thursday, September 14, 2017 1:39 PM
To: POI Developers List [hidden email]
Subject: Apache POI 4.0/Java 8

Hi,

FYI, as 3.17 is out and we agreed to work on 4.0/Java 8 now, I have done a
bunch of changes locally which switch to Java 8 and 4.0 and also use some
newer third party libs. I would like to do some more local testing on it
and then commit it tomorrow.

Just FYI so we don't duplicate efforts here.

Dominik.


    



signature.asc (495 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Apache POI 4.0/Java 8

pj.fanning
I agree with Andi about using 4.0.0-SNAPSHOT as the release number.
I'd like to make regular 4.0.x releases and to have 4.y release on a similar
cadence to the existing 3.z releases (2 or so a year).  



--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html

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

Reply | Threaded
Open this post in threaded view
|

Re: Apache POI 4.0/Java 8

Javen O'Neal-2
Are we following the guidelines of http://semver.org? If so, should we
declare that (possibly in the 4.0.0 release notes)?

Semver.org specifies that adding any deprecation warning would need to be
done in a minor release and any removal of a deprecated feature be done in
a major release.

This is a departure from our deprecate+2 releases rule for removing
features.

There are enough bits of the API worth changing that I think we'll be
spinning through major versions.

If we strictly follow semver.org, we'll need to bump the major version for
any backwards incompatible change, even if it's in scratchpad or some other
volatile module. At the same time, anyone using a module that isn't
actively developed, like hdgf, won't benefit from semantic versioning to
know that there weren't any backwards incompatible changes to hdgf from
4.0.0 to 5.0.0. How do we want to manage this? Maintaining different
package versions for each module sounds like a nightmare for devs and users
alike. Do we rely on bugzilla and the changelog to convey this information,
as well as our API Check build?


On Sep 16, 2017 18:47, "pj.fanning" <[hidden email]> wrote:

I agree with Andi about using 4.0.0-SNAPSHOT as the release number.
I'd like to make regular 4.0.x releases and to have 4.y release on a similar
cadence to the existing 3.z releases (2 or so a year).



--
Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Apache POI 4.0/Java 8

Mark Murphy
I think that a transition to 4.0.0 would indicate that things are
different. So maybe a repackaging is in order.

Semver states that anything with a 0.x.x version can contain breaking
changes at any time. It is a pre-release kind of thing. Our documentation
states that only the Excel package is stable, so I would expect that only
Excel would get a 4.0.0. Everything else would still be at 0.x.x. As an
interface gains enough stability to bring it out of the experimental stage
we could give it a stable version number. We could have users use something
like Maven to manage dependencies.

I would break packages into jars like this:
CORE - All common packages, file system (for now) v4.0.0
EXCEL - HSSF and XSSF v4.0.0
SCRATCHPAD - Everything else for the moment v0.4.0

Yes, we wouldn't be able to remove depreciated stuff as frequently, but I
don't see that as a big problem. We simply don't have to maintain
deprecated things as rigorously, when someone says a deprecated API has a
bug, we point them to the replacement.

On Sat, Sep 30, 2017 at 4:57 AM, Javen O'Neal <[hidden email]> wrote:

> Are we following the guidelines of http://semver.org? If so, should we
> declare that (possibly in the 4.0.0 release notes)?
>
> Semver.org specifies that adding any deprecation warning would need to be
> done in a minor release and any removal of a deprecated feature be done in
> a major release.
>
> This is a departure from our deprecate+2 releases rule for removing
> features.
>
> There are enough bits of the API worth changing that I think we'll be
> spinning through major versions.
>
> If we strictly follow semver.org, we'll need to bump the major version for
> any backwards incompatible change, even if it's in scratchpad or some other
> volatile module. At the same time, anyone using a module that isn't
> actively developed, like hdgf, won't benefit from semantic versioning to
> know that there weren't any backwards incompatible changes to hdgf from
> 4.0.0 to 5.0.0. How do we want to manage this? Maintaining different
> package versions for each module sounds like a nightmare for devs and users
> alike. Do we rely on bugzilla and the changelog to convey this information,
> as well as our API Check build?
>
>
> On Sep 16, 2017 18:47, "pj.fanning" <[hidden email]> wrote:
>
> I agree with Andi about using 4.0.0-SNAPSHOT as the release number.
> I'd like to make regular 4.0.x releases and to have 4.y release on a
> similar
> cadence to the existing 3.z releases (2 or so a year).
>
>
>
> --
> Sent from: http://apache-poi.1045710.n5.nabble.com/POI-Dev-f2312866.html
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>