We support defining the versions file, which allow...

# refreshversions

[louiscad]

We support defining the versions file, which allows you to share it with multiple projects. You'll only have irrelevant "unused" comments appear after running refreshVersions, and you'll want to run it from each project.

[Big Chungus]

Yeah, I wish I could disable those unused comments in settings.gradle.kts

[Big Chungus]

Otherwise I found symlinking my versions file to multiple builds in a monorepo to work flawlessly.

[dave08]

A possibly better option could be to have refreshVersions update the versions.properties file in both places AND not add the unused comments in such a case...?

[dave08]

That way the files could be cleanly committed to the respective git repos...

[louiscad]

Connecting two separate builds so we keep the relevant unused comments is not straightforward to me

[dave08]

Yeah, well that's a problem with composite builds in the first place 🙃

[dave08]

The idea is that currently, I need to diff the files (which doesn't diff well anyways) and manually change things so I can commit to the respective repos.

[dave08]

This way, refreshVersions would manage that for me and keep the versions files in sync... but you're right, which one is the source of truth...?

[dave08]

I mean, when running the refreshVersions gradle task, the current one would overwrite both files without removing anything else, but if running both concurrently, then it could be a problem...

[louiscad]

They would not run concurrently but sequentially, but the source of truth problem is still there

[dave08]

If nothing gets erased (other deps not in the current build), I'd assume the currently running one has the real versions needed. I usually go over all the deps in the file I need to upgrade before running refreshVersions.

But in any case, it might be an option to have a new comment when there's a problem in resolving the between the two?

[louiscad]

What's "a problem in resolving between the two", and what kind of this is "the two"?

[dave08]

the two version.properties (or more) included in the composite build. "problem in resolving", say when the current one is downgrading a dep the second one has... or maybe having a strict resolve option that gives a comment for any differences between the two, giving the user the option of deciding and avoiding diff tools that won't work so well in this context. There's also less chance a dev will forget to sync some deps even in the stricter mode...

[louiscad]

I think I'm seeing how such a thing would work, but since I don't need it myself at the moment, I don't think I'd invest the hours, days and weeks in designing and implementing it myself, especially since I already spend a lot of my free time in it.

If you want to implement it, we can do a remote pair designing session to at least lay out a plan so that you can make an implementation that we'll be able to merge and keep on the long run through refreshVersions evolution.

[dave08]

Yeah, I guess now that we spoke it out, it seems a bit more that "just a small addition"...

if I have time, I could try to take that up, only that lately, I've been pretty busy... 🤕. Thanks for the offer!