On 2022/01/07 11:40, Yifei Zhan wrote: > On 22/01/06 11:53AM, Stuart Henderson wrote: > > > > Since fcitx5 is meant to be the successor for fcitx4 which is no > > > > longer developed, it may make sense to replace fcitx4 with 5 instead > > > > of keeping both in the port tree? I'm not using either, so I'm > > > > probably missing something here. > > > > > > I agree, if Kevin is ok with that we can drop fcitx4 once fcitx5 and its > > > plugins are tested and imported. > > > > Wouldn't it make more sense to update the existing fcitx ports rather > > than add new "fcitx5" ones? > > > > I think it's better we keep both of them in our tree for a while so that:
We have found this approach doesn't usually work well in ports. > 1. users get more time to migrate their config and plugins Really it just shifts the point at which they have to migrate their config and plugins from when the new version is added to whenever the old version is removed. And in the meantime it makes it more complicated for users as they have to decide which to use. Unless somebody is actively following ports development they are unlikely to see/test the new version. (And if they are actively following ports development, they'll already have had a chance to test pre-commit!) > 2. if something is broken they can report the bug & fallback to stay on > fcitx4 until the bug is fixed. Existing users won't find a bug until they upgrade. And with software that is spread across multiple ports, that's a pain to do, if they even notice that there are two alternative versions available. Taking the other approach and replacing the existing ports: -current users test things sooner, so there's more chance of any bugs being found before the next OpenBSD release. They can also fallback by checking out an older version of the relevant ports if needed.
