https://kotlinlang.org logo
Join Slack
Powered by
<@U0B8SM5FX> is working on re-releasing our roboel...
# kotest
s
@alexfacciorusso is working on re-releasing our roboelectric plugin, and we're trying to decide where is best to locate it. So does anyone have any opinions on the following options: 1. release as part of the main project 2. separate repo, same version 3. separate repo, different versioning, with normal module names 4. separate repo, different versioning, kotestx module names
If we go with 1, it means we can't release on an independent cadence, but it might be easier to find. 2, 3 means users can have different versions in their build for different modules, might be confusing. 4 means introducing io.kotestx module names, like kotlin / kotlinx
a
Some examples: 1. 
io.kotest:kotest-extensions-robolectric:4.[latest]
 , meaning that any updates to the Robolectric extension would need to wait for a full release of kotest (it might slow down updates) 2. Same as 1 but would point to a different repo for an internal better management 3. Same as 1 but the version might be totally different than the main Kotest library (e.g. Kotest version 
4.3
 and kotest-extensions-robolectric 
1.0
 ). That would mean the release of an update of the Robolectric extension won’t have to wait for a kotest main library update 4. 
io.kotestx:extensions-robolectric:1.0
 , same advantages as 3 with a KotlinX-AndroidX-naming style
c
My vote would be for 1 or 4. I like all artifacts of a single project to have the same version to ease setup and help prevent version mismatches, or else be clearly identified which artifacts are maintained separately from the main project. With 2, it would eventually be the same version as the main project, but would probably lag behind a bit, which could confuse users during releases. Also complicates the release process as you’d have to release the main project first, and then release the robolectric module afterwards 3 is OK, but I generally prefer all dependencies for a single “project” to have the same version. But if you are keeping it in a separate repo, it’s best to just keep the versions separate to avoid confusion and enable each one to be released independently. 4 makes it clear that the robolectric module is maintained/versioned separately from the main project
s
I like 1 and 4 as well, but don't have a clear preference between them
c
I’d say that if you don’t have a great reason for picking 4 over 1, then go with 1 to keep versions the same and avoid confusion. I’m guessing the robolectric module isn’t going to have a significantly greater number of releases or significantly different development cycle than the main project for it to really be worth it
s
That is a good point. The argument for 4 is the android stuff doesn't play nicely with the rest of the MPP build.
a
I personally prefer the 4 since Kotlin (and Android) devs are used to the “x”-style like androidx and kotlinx so they would feel at home with it, plus that kind of solution has a double effect: it makes management of small groups of developers easier since each group can manage their “extension” in autonomy, and it makes PRs also more focused on that particular topic/lbrary
But that said, I’m not opposite any of the other solutions (yeah apart from the fact having an Android project for test together with MPP modules brings some more headaches, but I’m sure it’s solvable with some research)
l
I like 3 more than the other options
I believe that robolectric might actually be updated in a different timing than Kotest, such as having its version upgraded
It has happened before at least once
With different versioning, I think it's ok if it's very explicit on the documentation that Robolectric follows a different version
s
3 and 4 are the same other than io.kotestx vs io.kotest
l
I don't see a reason to move to kotestx
a
3 is 
io.kotest:kotest-extensions-robolectric
instead 4 is 
io.kotestx:extensions-robolectric
l
If we do that, we probably should do it for Klock, Konfirm, ....
s
If we move them out yes
Alex's argument is that if you do the -x thing, then it's clear they will have different versions
a
That's fair and true but the only problem is that if we keep kotest robolectric in the same package and artefact as the rest, a dev would expect it to have the same version
Yeah exactly
Hence a lot of confusion imho
d
Why not 3 with a bill of materials (bom in maven repo) to handle inluing the right versions?
s
Can't get a BOM to work with gradle and MPP
d
I don't understand anything about MPP really, but I did find this: https://youtrack.jetbrains.com/issue/KT-40489
s
Hmmm
3 Views
Open in Slack
PreviousNext
Powered by