GDevelop project's main JSON file gdVersion property purpose

[malec-palec]

Hi,

I wonder what the purpose of the gdVersion property in any GDevelop project's main JSON file is?
See example:

What is it used for?
And why does it never change?

[4ian]

Mostly outdated/deprecated. Used in the past to allow to warn against opening a newer version of a GDevelop project using an old GDevelop version. With auto-updates (both for desktop/mobile) and the web version (which is "evergreen"), this is mostly useless.

Note that this number is still the version number of the GDevelop "Core" library (the C++ classes). But this is largely irrelevant now.

[malec-palec]

Thanks for the clarification.

Do you have any objections to restoring this functionality?

to warn against opening a newer version of a GDevelop project using an old GDevelop version.

or at least just updating the actual version every time a project is built.

This will help desktop users with auto-update disabled. Or users who want to intentionally build a project using the exact version of the editor it was created in.
Also, it suits well for automation pipelines, e.g. building projects on CI/CD.

But this is largely irrelevant now.

If so, it won't hurt either.

[f0nar]

@4ian Hi! I had an issue around GDevelop version updating too.
I had custom extension that used RuntimeGame::getSceneData method. Few versions ago you changed it to RuntimeGame::getSceneAndExtensionsData so my extension crushed in runtime and I realized it so late...

So the functionality as

to warn against opening a newer version of a GDevelop project using an old GDevelop version

sounds awesome.

OR

Can we at least initialize gdjs.projectData.gdVersion with correct version of GDevelop on which project was build last time? In this case I can lock initial version in my extension and compare it with current one. It would be really nice. Let me know what you think

[f0nar]

@arthuro555 what if after some code changes it creates logical error instead of runtime one? IDE will not track it but with different version trackers or lockers I can specify and control behavior of my extension with different gd versions, make backup to last "white listed" version or smth else. I can choose and define flow by my own.
I mean it would be nice to have smart IDE but I think it is pretty complicated and smart flow that is not mass adopted. As for me I would like to start from smth small.

[f0nar]

@4ian what do you think? Maybe I can start with PR?)

[4ian]

Let's go with a PR :)
Whatever the use case, it would be better to have the gdevelop version actually sync'ed with the editor version.

[f0nar]

Hi!
I see that you have not been supporting runtime versioning for a three years already. As I understand this process was stopped with GDevelop 5 and js usage. I see that VersionWrapper and surrounding stuff is still there so probably the main part is to sync libGD version with electron-app/app/package.json one. Problem is that libGD should be ready and built before js part to satisfy correct pipe. My question is if you are bumping gd version by hand as i see a lot of "Bump version" commits or you are doing it by some kind of optimization? If it first case so I understand that there should be one additional rule as "bump version in VersionPriv.h too", right? I am talking only about approach and logic. I understand that there should be additional testing and changes.

[4ian]

@f0nar sorry for the delay! We're manually bumping GDevelop version indeed by updating newIDE/electron-app/app/package.json. This is also read by this script: https://github.com/4ian/GDevelop/blob/master/newIDE/app/scripts/make-version-metadata.js which generates a JS file that allows the editor to get the full version (as well as one with the git commit hash).

So we need to either:

• expose this version number to the C++ (by updating Core/GDCore/Tools/VersionPriv.h with a script?). For example, a Node.js script that would be run before GDevelop.js compilation. This would be a new task in https://github.com/4ian/GDevelop/blob/master/GDevelop.js/Gruntfile.js
• do the reverse: read or update newIDE/electron-app/app/package.json by reading VersionPriv.h (with a script that reads it and update the file).
• Something else? But if possible, let's avoid forcing 2 files to be updated. It would be cumbersome and error prone :)

At the end, we want something that is:

1. as simple as possible (so that's why I'm open to reverse the way it works)
2. that allows us to bump the version number (whenever we make a new official release) by changing one number and merging the changes (and then everything gets updated correctly).

Let me know what you think. I'm open to store the version in C++ and have the other files updated by scripts at compilation/npm start/something else.