Simplify Automated Dependency Updates

[DarkAtra]

Tools like renovate or dependabot have a hard time generating automated dependency updates for flapdoodle artifacts due to the fact that the spring boot version is contained in the artifactId (e.g. de.flapdoodle.embed.mongo.spring30x and de.flapdoodle.embed.mongo.spring31x).

Would it be possible to release flapdoodle under a single artifactId and use the version to differ between spring releases? E.g. something like:

<dependency>
    <groupId>de.flapdoodle.embed</groupId>
    <artifactId>de.flapdoodle.embed.mongo.springboot</artifactId>
    <version>4.10.1</version> <!-- for spring boot 3.1.x -->
</dependency>

<dependency>
    <groupId>de.flapdoodle.embed</groupId>
    <artifactId>de.flapdoodle.embed.mongo.springboot</artifactId>
    <version>3.10.1</version> <!-- for spring boot 3.0.x -->
</dependency>

[michaelmosmann]

@DarkAtra As the code does not differ for spring 3.0.x and 3.1.x you could just change the spring version. It would be better if the spring version would NOT be contained in the artifact.. but i am not sure, if everyone would be happy with this change.

If you have any idea how to solve this, i would welcome a PR for that:)

[DarkAtra]

hey @michaelmosmann, well the only thing i could think of is what i suggested above, e.g. relying on the artifact version to distinguish between spring boot releases and keeping the artifactId constant. However, i totally get that this might make others unhappy and is rather drastic.

Could you give me a few details about the release process? It seems like it's not automated with Github Actions and i also didn't find anything in the Jenkinsfile. Is it a manual process atm?

[michaelmosmann]

@DarkAtra yes.. its a manual process atm.. and i am not sure if it will work with these spring 2.5.x, 2.6.x and 2.7.x versions too..

[DarkAtra]

Another idea would be to leave the old versions as is, and only switch to the versioning described above for new releases (one for Spring Boot 3.2 is probably in sight). I think I could prepare a PR for this when I find some time.

[michaelmosmann]

@DarkAtra so would you expect a release with every new spring release?

[DarkAtra]

@DarkAtra so would you expect a release with every new spring release?

with the new naming schema - only if changes are necessary to keep the library functional. with the current one - i'd expect one for every SB major/minor release

[michaelmosmann]

@DarkAtra so the artifact could be de.flapdoodle.embed.mongo.spring3x instead with just rolling version numbers?

[DarkAtra]

@DarkAtra so the artifact could be de.flapdoodle.embed.mongo.spring3x instead with just rolling version numbers?

at least if there are no changes expected in sb 3.x. i'd personally stick with de.flapdoodle.embed.mongo.spring just in case a minor SB release introduces breaking changes but your idea would probably also work

[michaelmosmann]

@DarkAtra i will think about that.. an other way would be mark spring as provided so the spring version does not come with the dependency..

[michaelmosmann]

@DarkAtra i made a new release: https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo.spring/tree/spring-3.x.x .. where i changed from dependency-management for spring to provided dependencies.. please try to see if this works for you..

[DarkAtra]

@michaelmosmann thanks. i've switched to the new artifactId. feel free to close the issue, i will re-open if necessary - e.g. if dependabot and renovate still don't raise automated dependency updates

[michaelmosmann]

@DarkAtra your welcome:) .. i think i will change this for the other versions to and deprecate the spring30x and spring31x artifacts..