https://kotlinlang.org logo
Join Slack
Powered by
planning for the switch to `arrow-2`, we need a co...
# arrow-contributors
a
planning for the switch to 
arrow-2
, we need a couple of things to be ready: • publish snapshots once again (this should in principle be working), but we need to double check • publish docs in such a way that they do not override the 1.2.x ones volunteers for those tasks?
s
Hey Ale,
Most of that is already done ☺️ We only publish documentation now on a Github Release, but we could disable that for an RC release.
Publishing needs to be tackled, and Gradle needs to be simplified but I am willing to do that. I would postpone publishing until 
arrow-2
makes it into 
main
.
a
my fear is that we have now a "publish docs" workflow, which fails all the time, but maybe once we merge into 
main
this will override the API docs in the web
s
I'm going to double check that
That is publish and release docs, but it's completely broken. Publishing on 
main
is also not in a great state. We discussed this a while back, but I proposed to move away from Arrow Gradle Config and use https://github.com/vanniktech/gradle-maven-publish-plugin. For configuring Kotlin, I think you and me discussed either some high-level functions like 
configureWasm
, 
configureJvm(0
, etc or doing it in 
buildSrc
directly. My plan is to merge to main, and switch to Maven Publish Plugin. Semvar is still kind-of broken, so not to eager to switch back to that. I think I prefer 
SNAPSHOT
+ manually releasing versions from Github Actions by specifying a version.
WDYT? This would allow to merge to main today, and start working on this on main directly.
I should be able to migrate quickly to Maven Publish, and attempt to get an alpha or SNAPSHOT out today.
a
I'm totally fine with moving away from the arrow-gradle plugin... but I'm a bit concerned we may need to update every single 
build.gradle.kts
in the repo
s
but I'm a bit concerned we may need to update every single 
build.gradle.kts
in the repo
Same, not sure what the recommended approach is for KMP 😅 It seemed to have changed a couple times, back in the day everyone was just doing 
allprojects { }
but I read several times that's bad practice. We can also expose 
setupCommon()
from 
buildSrc
and invoke it in each file instead of adding the plugin.
a
I don't think most projects have 10+ libraries 😛
s
Well there are plenty of projects with 10+ modules, I am aware of a bunch with 100+
On Android, or KMP, it's extremely common
👍 1
Anyway, I was talking more about publishing. It requires almost 0 changes in Arrow itself, what we end up doing with the other config is still up for figuring out. I just don't think maintaining our own variant of maven publish, with less features, is worthwhile.
Also, Arrow Gradle Config publishing introduces some issues with Dokka which we have to work around in downstream projects
3 Views
Open in Slack
PreviousNext
Powered by