Hi. In general proposal looks good to me, but I agree with Andrey that
sticking to same *major.minor* is too much.
From my perspective using same major is enough. It still will make it
easier to understand correlation between spring
and corresponding extension module, meanwhile preserving enough room for
maneuvering.
For example, what it someone would like to develop some additional
features in the spring extension module,
in this case we supposed to increase minor version. So I don't see any
issues with having independent minor versions.
On 28.04.2024 19:50, Nusrat Shakarov wrote:
If we talk about semver(https://semver.org/)
You have the PATCH version for bug fixes.
But I agree, that we may want to make some improvement on the same Spring
version, and then the PATCH version won't be suitable.
If we keep major only, then my suggestion is not very useful(it will be
harder to understand correlation between ext version and spring version).
Maybe we can just upgrade the major version and ignore the spring version.
пт, 26 апр. 2024 г. в 13:46, Andrey Novikov<anovi...@apache.org>:
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.
