Alternative versioning scheme

[kuolemaaa]

Is your feature request related to a problem? Please describe.

Since this project is based on the original server with the addition of your dashboard and your other stuff/fixes I think it is reasonable to change the version scheme to a more descriptive one until the two projects diverge without possibility of reconciliation (well, not a proper reconciliation since you are adding on top of that and the vice-versa not gonna happen anyway soon :-) ).

Describe the solution you'd like

Adopt a version scheme that is {your-scrgdesk-server-version-scheme}+rustdesk-{original-version-based-on}

Let's say that the version of your dashboard and additions is called 1.20 and the original version which is based on is the (actual) desk-server that is released and called 1.1.12. You started at 1.1.99 I really don't understand why.

The final version name of your release will be 1.20+rustdesk-1.1.12

• When you will update your work, you will bump up the first part of the version 1.20 -> 1.21
• When you will rebase your work to an updated version of the rustdesk server you will bump up the second part according to the version1.1.12 -> 1.1.13

---

• rustdesk-server -> 1.1.12
• sctgdesk-api-server -> 1.1.99 (or whatever you want)
• sctgdesk-server -> 1.1.99+rustdesk-1.1.12

Describe alternatives you've considered

No alternative. This is good practice.

[aeltorio]

Good idea

[aeltorio]

How can we reflect that rustdesk-server itself diverge for example rustdesk-server does not have tcp mode (but pro version has) ?

[kuolemaaa]

How can we reflect that rustdesk-server itself diverge for example rustdesk-server does not have TCP mode (but pro version has) ?

Interesting problems. I need to have a look at the whole codebase in order to have a strong opinion on that and I don't have time for that but I would love to.

Having said that:

• It is still true that you are basing your additions on the rustdesk-server non-pro version.
• It is also true that (correct me if I'm wrong) your addition of the TCP mode is your personal implementation of a feature in the pro version, but you are adding that on top of the vanilla one. It is your view of such TCP mode, your work, not rustdesk team implementation. It is under your control, it is under your versioning. In a sense it's just a personal patch for the rustdesk-server.

Now, I repeat that I need to look at the whole codebase and in particular to the api server thing and the two server entities that are the hbbs and hbbr, which is primary which is secondary, which one can be replicated, etc etc. I don't remember these detail.

• Is the api server another binary? or is it another subprocess/thread inside either hbbs or hbbr that listen on another port? I need to look at it.
• Is the TCP mode a feature of hbbs or hbbr ? Can you link me some documentation? What is that for?

Please, answer these two question if you want.

Since I am ignorant about the codebase organization, listening to my gut and not my mind, I would reorganize your work in something else. My guts are telling me that both TCP mode addition and API server thing belong both to either hbbs or hbbr and since that I would incorporate both element in a single project called sctgdesk-server that has that versioning scheme I talked about. But still: if the TCP mode is an addition for hbbr and API server is an addition for hbbs I would still go ahead with this idea (if it is feasible).

I'm not that good with words and not good in describing what happens inside my mind. Feel free to ask questions.