Java 17 is the target for POI 6.0.0. The current Java 11 support in trunk branch is transitional.
On Thu, 4 Jun 2026 at 12:58, Shuxin Pan <[email protected]> wrote: > > I’d also like to move to the latest version eventually. My only > concern is that we still have quite a few users running on Java 8 > today, so raising the minimum requirement too early could create > unnecessary friction for adoption. > > Perhaps during incubation we keep things simple and continue > supporting Java 8. Once the project graduates and the community grows > further, we could consider maintaining two major release lines for > some period of time: one for Java 8 users and another based on Java > 11. > > > Best, > Shuxin Pan > > On Thu, Jun 4, 2026 at 7:40 PM Bengbengbalabalabeng <[email protected]> > wrote: > > > > I agree with the proposal of keeping the policy simple during > > incubation for now. Considering our dependency on Apache POI, Could we > > consider referencing the versioning and Java support strategy of > > Apache POI? Following the release of Apache POI 6.0.0, initiate a > > major version upgrade to raise the minimum requirement to Java 11. > > Concurrently, maintain security updates for Apache POI 5.5.x. > > > > Best, > > Bengbengbalabalabeng > > > > Shuxin Pan <[email protected]> 于2026年6月1日周一 23:35写道： > > > > > > Hi all, > > > > > > While working on recent release planning, I realized that we have not > > > yet formally defined a version support and release maintenance policy > > > for Apache Fesod (Incubating). > > > > > > As a podling, our development is still evolving rapidly, and our > > > community and user base are continuing to grow. My initial thought is > > > that keeping the policy simple may be the most practical approach at > > > this stage. > > > > > > For example: > > > > > > - Only the latest release line is officially supported during incubation. > > > - Users are encouraged to upgrade to the latest available release. > > > - Bug fixes and maintenance updates are generally provided only for > > > the latest release line. > > > - Older release lines may not receive additional fixes unless the > > > community decides otherwise. > > > > > > After graduation, or once the project reaches a more mature stage, we > > > could revisit this policy and consider maintaining previous release > > > lines for a limited period of time. > > > > > > I'd like to hear how others think we should approach: > > > > > > - Version support expectations > > > - Maintenance of older release lines > > > - Patch release strategy > > > - Criteria for declaring a version no longer supported > > > > > > Please share your thoughts and experiences. > > > > > > Best regards, > > > Shuxin Pan > > > > > > --------------------------------------------------------------------- > > > 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] > > > > --------------------------------------------------------------------- > 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]
