Roadmap as of 2019-01-09

[laurent22]

The goal of this mini-roadmap is to bring the project to a state where outside contributions can more easily be added. This can be done in particular by having test units for the front end (backend is already covered) and by having a way to release beta versions.

If you have any suggestion, feel free to post here. The reason I'm publishing it is because I'm freezing new features and no longer accepting pull requests till the items below are completed. Pull requests that have already been submitted will be merged if possible.

• Freeze new features for now
• Merge what can be merged in existing pull requests (but don't accept new ones)
• Finish fixing remaining bugs in Essential tag (unless too complex to fix).
• Create Android release
• Create iOS release
• Create Desktop release
• Fix terminal app (search engine) and release
• Handle beta releases: implement command node release-electron --beta, which will do the same as now but will automatically tick the "pre-release" box. If this box is ticked, don't display this update in auto-update. Add option in desktop to upgrade to pre-releases.
• Test units for desktop app
• Test units for mobile app

[tessus]

As part of the beta release item, I think a small change should be made to the upgrade dialog. Well, maybe the change to the dialog has nothing to do with beta releases, it depends how you see it.

Actually there are 2 items that should be considered:

• a setting for the update channel in the configuration (release/beta)
• information in the update dialog which version you are currently using and which version is available

What do you think? Does this make sense?

[laurent22]

a setting for the update channel in the configuration (release/beta)

There's a new option for this.

information in the update dialog which version you are currently using and which version is available

This would still be the same version number as there won't be separate release and prerelease builds. It's just that in some cases, the prerelease checkbox will be ticked on GitHub so that this version is only available to those who choose so.

[tessus]

This would still be the same version number as there won't be separate release and prerelease builds. It's just that in some cases, the prerelease checkbox will be ticked on GitHub so that this version is only available to those who choose so.

No, I think we are talking passed each other. Let me give you an example.

On one machine I'm currently on 1.0.119. On the release channel, I would get an update notification, but it wouldn't tell me that the version available was 1.0.120.
I would like to see in the update dialog that I'm running 1.0.119 and that 1.0.120 is available.

Now, here's the next slight problem. If you switched to the beta channel, you'd get an update notification again. (Btw, I just saw that you removed the prerelease and made it a draft again.)
But the notification wouldn't tell you that version 1.0.123 were available, nor that it actually were a beta version.
The next problem is that you will not know, if any of the future updates will be a release (stable) version.

All I'm saying is that the upgrade dialog should tell you the following information:

• current version (+ if it's release or beta)
• available version (+ if it's release or beta)
• changelog

[laurent22]

Yes that makes sense and would be useful. I'll check if can be added.

[laurent22]

Looks like test units for the front end aren't going to happen for now. It's just too complex and time consuming to put in place. Test units for the backend will keep being maintained and expanded though since this is the important part that deals with user data.

[WqyJh]

How about add some architecture documents that help contributors quickly understand the data storage/flow and other mechanisms?