well, I think the title is eslf explaining enough. I take this screenshot yesterday (2020 sept. 06.)
The auto-updater doesn’t really check which version is the latest, the devs decide which version should be considered the latest.
When new versions are released, the update is often manual during the first days/weeks, to avoid spreading a nasty bug that was not noticed before release.
When the version is deemed safe by the devs, it is advertised to the auto-updater.
And it also happens that the devs forget to update the auto-updater. 
is it possible that later versions have less feature in total?
is compatibility of apps in later versions is always more and updated?
by later version i mean greater no. 98,99,100
It’s very unlikely that a feature is removed, because it creates problems for existing projects, but it’s possible, yes, if a critical bug was found or if a feature was deemed obsolete.
For instance, I would recommend removing the “Blur” layer effect because it’s very buggy and there’s another blur effect.
If a feature was removed, it would be noted in the release notes (aka “What’s new?”)
Always read the release notes. 
what do you mean: update the auto-updater?
by the way in the case of b98, you published it immediately, no one bothered its buggy…
but anyways, so I just have to wait?
Either you wait, either you update manually by going to the github: Releases · 4ian/GDevelop · GitHub
I meant that the auto-updater is automatic for us users, but it’s not automatic for the devs, they update it when they feel the version is ready for everyone.
1 Like
except for b98 
ok. I understand now. I think I figured out what causes the misunderstanding: the bad communication of developers. for example the bad naming. I think not a good solution give the exact same name to the test version and the “final” versions. I mean the latest official version is still a beta version, because the whole game engine is in beta phase. and the newly released (not approved) test version is still called a beta version. there is no difference in their names, though there is a difference between them.
i think they should be distinguished by their names! elsewhere they do so. for example we mark the official (approved by the developers) versions wit “b” (beta), but the not approved versions should use something different. for example: “a” (alpha), “e” (experimental) or “tv” (test version).
so when the user see the new a101 is out, he/she know, it isn’t an official release yet. but when he/she see the new b101 is out, he/she know this is the official release! this should be given to the automatic updater. in my opinion.
The development is very active, each update brings new features, so all the releases are beta because when a new update comes out, nobody knows how many bugs will be found in the new features.
Time decides if the version is good enough to be pushed to everyone, the devs can’t decide this before release.
It would be nice to have a stable release, but it’s a lot of work of bug fixing and testing.
The github currently has 230 open issues. I don’t think there’ll be a stable release unless that number is down to almost 0.
1 Like
and what’s wrong with the different markings? why can’t versions be marked with different letters?
Because they’re all beta
Alpha would mean it’s not fully usable, it’s incomplete. That’s not correct.
I don’t understand this. this is just equivocation.
Alpha is like the phase of the core building.
How are translate to javascript the eventsheet, how are initalized and updated the objects.
Beta is more we adding more feature and fix bugs, note some features can be deleted, but this goes rarely.
Beta is also a stage where the dev are not satisfaying about some features, then these features can be changed.
For example I’m not at all satisfied with the collision system, it’s not very flexible. Making a hitbox in a small window with positions and only convex shapes is very limiting.
A debug view of the collisions in the editor would also be great.
Collisions on painter shape objects are non-existent.
And this is only my feeling for the collisions ^^
Stable is just an version with less bug than another build, and this version is frozen. (No new features, no fix)
And this mean we should support two canals, one stable and one in dev, this mean also double the infrastructure of server for the online build.
I would like see two canal too, maybe it’s yet too soon. As long as we have the tag beta, we can continue to add features, fix bug, and have a fast developpement and fast feedbacks with the lastest version.
I see many developers contribute very unique and different features. Many are working with very valuable extensions. I think it will be good to mention their real names in the engine.