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.
> >
>

Reply via email to