Thanks for the clarification. I wasn't aware that Java 11 support in trunk was only transitional. That certainly gives us a bit more to think about for our future release planning.
On Thu, Jun 4, 2026 at 8:21 PM PJ Fanning <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
