Unvanquished Forum

This is a poll for developers about whether and how we should keep a log of Daemon changes which affect APIs used by the gamelogic, or otherwise impact building gamelogic against a given Daemon version (see Unvanquished issue #3230). The point is to help modders when rebasing their code or other Daemon-based games.

The poll just talks about Daemon changes, but I believe that in many cases seeing the Unvanquished commit that adapts to the API change would be more uses. Option (C) might be better for that, since storing information outside the source code repositories permits linking to the changes on both sides. Also something similar to option (B) could be used in the Unvanquished repository (i.e. writing something like [daemon-api-migration] in the commit messages), regardless of what is done on the Daemon side.

A. I don't think the mutual conflicts will really be problematic in practice.

whatever creates the least overhead for those that have to maintain that list.
as long as the information is somewhere its better than nothing.

how about having a changelog folder instead of a single file? anyone interested can create a list from it and there are no merge conflicts.

I also thought about a changelog folder, and I was going to suggest that.

The idea would be such layout:

changelog/0.56
changelog/0.55

The benefit would be to avoid completely any changelog merge when merging master to future branches.

Solving merge conflicts when pushing branches should be easy, and I want the changelog to be part of the code so we can request a changelog modification as a requirement for merging.

Ah interesting i didn't think about merging master to future. I thought this is about conflicts with multiple PRs at the same time.
My idea was to have one file per api breaking PR and optionally, in case they become to many, have them added to a changelog file every release.

Ah, that's a good idea too.

Though I believe having one file per change is a bit too much, the merge conflicts coming from having a single file per engine version are very easy to solve (it's only a matter of keeping all the lines from both sides).

But having one file per major version makes it easy to automatically merge master into future branch, so I think we will do that.

I like Gireen's idea of one file per change. That solves my concerns about merge conflicts (I am concerned about merge conflicts between PRs, not just from the compat-breaking branch).

Is there any way to see who has voted? I am curious whether any of them come from real mod developers

killing time wrote: ↑Thu Jan 09, 2025 7:27 am UTC

Is there any way to see who has voted? I am curious whether any of them come from real mod developers

No

Is there any way to see who has voted? I am curious whether any of them come from real mod developers

I voted for "do nothing". But I am not really a mod developer, all I do is base my own experiments on top of the upstream Unvanqished master branch.

Sweet wrote: ↑Fri Jan 10, 2025 10:29 am UTC

I voted for "do nothing". But I am not really a mod developer, all I do is base my own experiments on top of the upstream Unvanqished master branch.

That counts. You may hit API changes when rebasing the experiments.