4.1.0 changes public interface (non-semver API change?) about ftxui HOT 10 CLOSED

You are right. I made a mistake when cherry-picking this patch into v4.1.0 a few days ago.
Not sure what's best from here.
Unpublish v4.1.0 and release v4.1.1 removing this commit.
Or maybe directly change the v4.1.0 reference.

from ftxui.

Please don't change the reference of tag v4.1.0. If you do that, people will have v4.1.0 checked out without knowing if they have the old or new 4.1.0. Just increase the latest number and make it v4.1.1. The latest number is meant to be increased when patching, so it is meant exactly for this purpose.
You will never ever run out of numbers, so please don't be afraid to use them. There will always be plenty left 😉

from ftxui.

v4.1.1 is going to be a breaking change relative to v4.1.0.

I think I am going to keep the v4.1.0 git tag, but unpublish the release from github.

from ftxui.

Also I think it depends if you want to have this commit in the 4.x series.
Considering that you released 4.1.0 only 3 days ago, I think it would be ok to have a 4.1.1 which has an API break with 4.1.0.

However if you want to keep the change, there could be ways to make it compatible with the previous API.
In the MenuOption class, I thing you could do:

class MenuOption
{

using Right = Direction::Right;
using Down= Direction::Down;
//..
}.

I think this way, users can still reference MenuOption::Right and the code will continue to work.
You could again remove the using directive for your 5.x release.

We often do stuff like this, when we want to introduce new APIs, but not break SemVer....

from ftxui.

Hi @KerstinKeller & @FlorianReimold

The branch https://github.com/ArthurSonzogni/FTXUI/tree/support-v4 is going to become v4.1.1. It should be good and not breaking v4.0.0. This time, I won't rush. Could you please take a look and tell if this is good?

Unfortunately, there was no way to have a "soft" fix without breaking v4.1.0. That's because the breaking change renamed both Direction into WithOrHeight and GaugeDirection into Direction. We can't have Direction means multiple incompatible enums.

from ftxui.

I updated to the current HEAD of support-v4 in a branch in our eCAL Repository. The results will ready in in about 1h or so:

https://github.com/eclipse-ecal/ecal/tree/testing/ftxui_4.1.1

Ubuntu 20.04: https://github.com/eclipse-ecal/ecal/actions/runs/5089121687/jobs/9146373055
Ubuntu 22.04: https://github.com/eclipse-ecal/ecal/actions/runs/5089121663/jobs/9146373082
Windows (VS 2019): https://github.com/eclipse-ecal/ecal/actions/runs/5089121665/jobs/9146373351
macOS: https://github.com/eclipse-ecal/ecal/actions/runs/5089121666/jobs/9146373086

from ftxui.

Thanks!

The macOS version had an issue, because C++17 was not applied to the dependant (ecal). I pushed a few more CLs to fix the issue. If you can retry before I publish it, it would be greatly appreciated! (@FlorianReimold)

from ftxui.

I think the fix was good, so I will publish v4.1.1

from ftxui.

https://github.com/ArthurSonzogni/FTXUI/releases/tag/v4.1.1

from ftxui.

The macOS version had an issue, because C++17 was not applied to the dependant (ecal).

Yep, I realized the mistake and pushed another commit that I didn't link here. Just going to C++17 worked well for macOS

If you can retry before I publish it, it would be greatly appreciated! (@FlorianReimold)

Well, that probably is too late now 😀
But I updated to the 4.1.1 tag you released:

Ubuntu 20.04: https://github.com/eclipse-ecal/ecal/actions/runs/5118599237/jobs/9202815300
Ubuntu 22.04: https://github.com/eclipse-ecal/ecal/actions/runs/5118599220/jobs/9202815520
Windows: https://github.com/eclipse-ecal/ecal/actions/runs/5118599226/jobs/9202815385
macOS: https://github.com/eclipse-ecal/ecal/actions/runs/5118599221/jobs/9202815295

Edit: ✅ Compiles on all plattforms

from ftxui.