> > 5. New versioning approach. Use the same major and minor for spring > extension as the corresponding spring module is used.
What if we need to fix some bug in the module without changing the corresponding spring module version? I would prefer independent versioning from spring, but it is fine to change that major version for the module On Thu, Apr 25, 2024 at 11:31 PM Nusrat Shakarov <nusrat...@gmail.com> wrote: > Hello everyone. > > I've created an epic to implement spring 6 support for ignite extensions. > https://issues.apache.org/jira/browse/IGNITE-22096 > > Spring 5 support is ending(and has already ended for some modules). And not > all spring-extensions work correctly in the spring 6 environment. > In the epic, I've described a plan. Key changes are: > > 1. New pipeline on public tc with JDK 17, because spring 6 baseline is > 17. > 2. If the current extension doesn't work in spring 6 environment, update > it to spring 6. > 3. If it is necessary, it still will be possible to make changes to the > previous version(checkout from corresponding release version, > cherry-pick > change and release). > 4. Add compatibility test to spring 5 extensions, that should work in > spring 6 environment. > 5. New versioning approach. Use the same major and minor for spring > extension as the corresponding spring module is used. For example, If > spring-session-core is updated to 3.2.2, the spring-session-ext version > should be 3.2.x, where x is the revision number. > > > Pls, share your thoughts and opinions. > If no one objects, I would like to start implementation. >
