Ferdi: User can not add custom service

[LVladymyr]

Steps:
Try to add custom recipe.

Expected:
User can add any kind of recipe.

[vantezzen]

I can't reproduce this bug. Could you please provide me the following information:

• Your OS and OS Version
• Your Ferdi version

[LVladymyr]

OS Name Microsoft Windows 10 Enterprise
Version 10.0.16299 Build 16299
Ferdi:
Version 5.3.3
Electron 4.2.4

[LVladymyr]

In next version:
Version: 5.3.4-beta.6
Electron: 6.0.10 / win32 / x64
This behavior is fixed.

[kytwb]

In case someone is running into the same issue, don't forget to include beta versions when checking for in-app updates:

[Ryonez]

Just popped in about this bug as well.

What's the expected time frame for this to hit stable?

[kytwb]

@Ryonez We keep our stable version in sync with Franz, so next stable release will be out around the same time as Franz's next stable release. In the meantime, we recommend you include the beta versions when checking for in-app updates as mentioned above to get all the latest Ferdi's features/fixes.

[Ryonez]

Got it, thanks for the info.

[vantezzen]

@kytwb I thought we settled on this:

I also think we could release new patch versions of Ferdi without Franz having that version yet (e.g. 5.3.3) if we want to release new features for Ferdi
#7 (comment)

In that case, we could publish our changes as 5.3.4 without waiting for Franz.
It also looks like Franz developers are currently working on a 5.4.0 release and are not adding anything to 5.3.X. I think that it will still take some time until the next Franz release, 5.4.0, gets published.

[kytwb]

@vantezzen thanks for the reminder, I honestly forgot and just kept going with the betas as it seemed to be working pretty well. The only thing I see now is: what happens if we minored up before Franz on, let's say, 5.4.1, then sync to include the patches from Franz. They will be available in 5.4.2 while needing to reference merging Franz 5.4.1 into Ferdi 5.4.2, is that right?

[vantezzen]

Yes, thats right. At least in my opinion this isn't too critical as it is only the patch version that isn't in sync.

[kytwb]

What about making beta updates checked by default and maybe adding a small in-app text to explain that the stable version is kept in sync with Franz, but we recommend getting the latest betas to enjoy Ferdi's very own latest features/patches?

Like this when we release a stable and indicate we merge Franz stable into Ferdi, we can link to Franz own changelog for people to catchup quickly on what was inherited from the original repository (in addition to the list of Ferdi now stable features/patches previously listed in all the betas)?

Otherwise I'm also ok with sticking with what we previously agreed on, should also be manageable too.

[vantezzen]

I understand your arguments for using beta versions as release versions, but I also think it is nice to have a release channel that users can test if new features work as intended before publishing to all users.

I looked into how electron-updater works and it looks like it determines whether a release is a pre-release based on if it is marked as pre-release in GitHub. My idea would be to name Ferdi release versions as 5.X.X-ferdi.Y with X.X being the next Franz release and Y being the release version of Ferdi.
This would mean that our next update is 5.3.4-ferdi.1. As soon as Franz releases 5.3.4, we can merge and release it as Ferdi 5.3.4 without problems.

electron-updater uses the semver package to check versions. Here is a demo of the update process to a ferdi-prerelease: https://runkit.com/embed/3kxs7ye7nq97, here is a demo of the update to a full Franz release: https://runkit.com/embed/xg4f2ce7oho3.

[kytwb]

Regarding the beta channel, it's better to keep it for that purpose for the longer term, you're right. Following your new versioning proposal, the beta channel would then be X-ferdi.Y-beta.Z, right?

[vantezzen]

No, the beta channel would still be 5.X.X-beta.Y (e.g. 5.3.4-beta.3).