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]
