> My proposal is not about creating a separate repository for the spring-data
extension - just left a single module

Yeah, you're correct. I mean that we need a single point of truth for
spring-data - single repository or single module. I'm +1 here.

> So creating some branches to store obsolete code for a module seems a bit
confusing

IMHO, we should have an opportunity to release a hot fix asap for those
modules in case of critical CVE, particularly if it is impossible to just
make an upgrade from 2.0 to 2.2 or to the latest version due to backward
compatibility.

WDYT?

On Fri, Feb 18, 2022 at 2:12 PM Mikhail Petrov <pmgheap....@gmail.com>
wrote:

> Maksim,
>
> Currently, we have a single repository where all extensions are stored
> as separate modules - [1]
> My proposal is not about creating a separate repository for the
> spring-data extension - just left a single module for the spring-data
> extension and proceed with its developments the same way as for other
> extensions - [2].
> So creating some branches to store obsolete code for a module seems a
> bit confusing.
>
>
> One of the goals of this refactoring is to create the Spring Data
> integration extension that will be independent of the version of Spring
> Data.
> (as it is already done for Spring Cache or Spring Transactions
> integrations). It must be updated and re-released only in case of broken
> backward compatibility between Spring Data versions or if the extension
> itself is updated. This process is described in the thread - [2].
>
>
> [1] - https://github.com/apache/ignite-extensions/tree/master/modules
> [2] - https://lists.apache.org/thread/wox65gp3fyjkx048205t9omm418o3f20
>
> On 18.02.2022 13:13, Maksim Timonin wrote:
> > Hi Mikhail,
> >
> >> remove extension modules that are tied to the specific Spring Data
> versions
> > - keep only a single spring-data-ext module. For now, it will contain
> code
> > for the latest Ignite Spring Data integration -
> ignite-spring-data-2.2-ext.
> >
> > I'm +1 for having a single repository for the spring-data extensions.
> But I
> > think we must not completely remove code for 2.0, 2.1 versions. I'd
> propose
> > to create separated branches in the repository for those versions, and
> put
> > tags for already released versions.
> >
> >> According to [5] 1.0 and 2.0 versions are no longer supported
> > According to this 2.2 isn't supported too, the last release was a year
> ago,
> > is it? Do we have plans to support spring-data with the latest version?
> >
> > On Fri, Feb 18, 2022 at 10:57 AM Mikhail Petrov <pmgheap....@gmail.com>
> > wrote:
> >
> >> Igniters,
> >>    Currently, we have three separate modules for Ignite Spring Data
> >> integrations - [1 - 3]. Each of them depends on the specific version of
> >> the Spring Data - 1.0, 2.0, and 2.2, respectively.
> >>
> >>    I propose to:
> >>    1. remove extension modules that are tied to the specific Spring Data
> >> versions - keep only a single spring-data-ext module. For now, it will
> >> contain code for the latest Ignite Spring Data integration -
> >> ignite-spring-data-2.2-ext.
> >>    2. Proceed with spring-data integration future releases as were
> >> discussed here - [6].
> >>
> >>    Motivation:
> >>    1. Almost all bug fixes or improvements for the Spring Data
> >> integration are copied multiple times for each module
> >>    2. According to [5] 1.0 and 2.0 versions are no longer supported and
> >> since the corresponding integrations were already released, we can
> >> remove them safely.
> >>    3. Some patches already neglect versions 1.0 and 2.0 - [4]
> >>
> >>
> >> WDYT?
> >>
> >> [1] -
> >>
> >>
> https://github.com/apache/ignite-extensions/tree/master/modules/spring-data-ext
> >> [2] -
> >>
> >>
> https://github.com/apache/ignite-extensions/tree/master/modules/spring-data-2.0-ext
> >> [3] -
> >>
> >>
> https://github.com/apache/ignite-extensions/tree/master/modules/spring-data-2.2-ext
> >> [4] - https://github.com/apache/ignite-extensions/pull/41
> >> [5] -
> >>
> >>
> https://mvnrepository.com/artifact/org.springframework.data/spring-data-commons
> >> [6] - https://lists.apache.org/thread/wox65gp3fyjkx048205t9omm418o3f20
> >>
> >>
>

Reply via email to