A long time ago (maybe for 4.0 or 5.0) we split ou...
# kotest-contributors
s
A long time ago (maybe for 4.0 or 5.0) we split out a bunch of extensions into their own repos. The idea was we could quickly iterate and release without needing a full kotest release. However, that was a noble idea, but in practice, those repos are just left to languish as many people don't know they exist. So I'm proposing we fold some of the extensions back into the main repo (eg arrow, ktor). What do you think ?
l
I'm ok with that. Personally didn't feel much of a difference, but I don't have the same visibility as you
s
We wouldn't need to change any maven coordinates so no impact to users
l
A bit of DX problems if people get trouble to compile eg. arrow-extensions module on their pc while trying to contribute to Kotest
e
will the extensions still have their own versions? or will they all be v6.0.0 when that happens?
s
6.0.x but that's just like bumping to new versions anyway. Nothing is higher than 5.x atm
l
But they wouldn't walk independently of the main version
s
Correct
Just like we have just done with yaml extensions
e
sure, just asking 🙂 I think there's a few pain points. Split repos are harder to maintain w/ regards to build scripts etc.. It could be addressed either by moving everything back, or by creating a separate gradle plugin repo (like arrow org did) Discoverability (of extensions etc), I think this mainly happen through docs / homepage?
s
Discoverability I think is ok right now because as you say - docs. But we've not done a great job keeping these side projects up to date and released imo.
e
100% agreed. Personally, I find it hard to work on maintaining an extension that I never actually use. Mostly come across Spring / Wiremock / Arrow @ work. Trying to fix issues popping up for the Allure extension is hard as hell cause I have no idea how it should even be working 😄 I think our current setup might be easier to deal with for new contributors just looking at a single extension (Koin. arrow, quarkus, w/e) w/o needing to deal with the entire Kotest framework/engine/assertion thing as well. Maybe it would be good to have some sort of responsible maintainer(s) per repo, and actively try to bring someone on board for the repos lacking some love?
s
That's one option. The other argument is that one repo means when we change things we know it works with the aligned version. Some of the bugs are often just breaking changes we forgot to test on an extension we forgot existed.
e
Yeah true, I see that happening every now and then. Moving them back would definitely help in that regard