OFFICIAL Upcoming GameMaker releases

rwkay

GameMaker Staff
GameMaker Dev.
This September, we'll be releasing an update for the LTS, aimed at addressing SDK updates, bug fixes, and submissions. We'll be releasing the complete release notes toward the end of the month.

Rather than trying to force ourselves to release a Monthly build at the same time, we've decided to roll the October update plans into one big November release instead.

That means there will be no Monthly Release in September or October. This will give us the time we need to ensure that both the LTS update and the November Monthly Release are the best they can be.

It also means that we won't be releasing any betas in September. These will debut in October once work on LTS is complete.

You’ll be able to follow progress on the November release on github Roadmap November Bugs.

The roadmap will be updated soon too.

Happy GameMaking!

Russell
 

Evanski

Raccoon Lord
Forum Staff
Moderator

maybe im pessimistic, but the last few times you guys bundled updates like this their was multiple bugs that required a hot fix patch
 

Ratoneone

Member
Not sure I understand correctly, so this means that this bugfix:

Will only come in October?
Or is there hope for a hotfix? This is basically a game breaking bug on HTML5, with a simple (already done from what I see) fix.
 

Andrey

Member
I'm sorry, but what about the new New Runtime? Somehow everything has calmed down since June. Is there any new information?
 
Just my opinion;

I can't help but get the impression you guys are overwhelmed with juggling 3 different releases (monthly, beta, LTS) on top of your other workload. I think it'd be better to narrow it down to 2; a stable release and a beta/preview/test release. I think many will rather prefer seeing sparse updates with as little bugs as possible on the stable, and be ok/understanding with bugs in the beta than current state. I don't even think many will install all 3 different releases on their hardware., because I don't. I used to have monthly and beta. I've since uninstalled beta. With 1 less release to manage, some staff members could be reassign to take care of other matter, i.e. write or record tutorial blogs/vblogs, make sample projects, update extensions, rejuvenate the marketplace, etc.
 

AIO1

Member
All of this being my personal opinion and recommendation...

I think it can be a good idea to reduce the current amount of delivery to increase the quality.
However, this could lead to people losing interest in the engine. The delivery of fixes and new features is what normally keeps people interested in the engine. It's... a tricky balance.
On Android there are already behind in the Android Studio version and supported API version (in the required SDK it recommends up to API 33 and API 34 has been already released for some time).
Feather still has some annoying warnings which need to be fixed.

I think there is no obligation to make monthly releases, and each 2-3 months should be totally OK (unless a critical bug has been identified).
It would be great to have a Beta one month in advance of a Stable for example, which gives some time to fix any critical issue found.

For example, a year roadmap could be (always publishing the last days of a month):

Jan: Beta
Feb: Stable
Mar; Nothing
Apr: Beta
May: Stable
Jun: Nothing
Jul: Beta
Aug: Nothing
Sep: Stable
Oct: Beta
Nov: Stable
Dec: Nothing

This ensures that normally there is one month with no releases at all, and, in the normal month of vacations (Aug and Dec) there are no releases done.
 

efeberku

Member
All of this being my personal opinion and recommendation...

I think it can be a good idea to reduce the current amount of delivery to increase the quality.
However, this could lead to people losing interest in the engine. The delivery of fixes and new features is what normally keeps people interested in the engine. It's... a tricky balance.
On Android there are already behind in the Android Studio version and supported API version (in the required SDK it recommends up to API 33 and API 34 has been already released for some time).
Feather still has some annoying warnings which need to be fixed.

I think there is no obligation to make monthly releases, and each 2-3 months should be totally OK (unless a critical bug has been identified).
It would be great to have a Beta one month in advance of a Stable for example, which gives some time to fix any critical issue found.

For example, a year roadmap could be (always publishing the last days of a month):

Jan: Beta
Feb: Stable
Mar; Nothing
Apr: Beta
May: Stable
Jun: Nothing
Jul: Beta
Aug: Nothing
Sep: Stable
Oct: Beta
Nov: Stable
Dec: Nothing

This ensures that normally there is one month with no releases at all, and, in the normal month of vacations (Aug and Dec) there are no releases done.
I think if there is no deadline the progress will be very slow. There must be monthly deadline. But 1 month implementation then next month bug fix cycle is also acceptable.

I also want SDK updates in every 6~ months. (If there is no emergency.) This will keep the SDK's updated all times of the year.

With every update they add, file size of my APK - AAB increases. I wonder if we can do something about that. Because we are not changing anything but the file size still increases. (30mb just for one architecture .so file) (I wonder if they can add something like proguard to the new runtime or making it modular. (If we are not using something then it shouldn't get included in the final package.))
 
Last edited:

gnysek

Member
I'm sorry, but what about the new New Runtime? Somehow everything has calmed down since June. Is there any new information?
It might look that it calmed, as closed beta testers aren't allowed to speak what they know, but that doesn't mean nothing happens. From Discord talks "open beta" is still planned this year (but I suspect that it would somehow be aligned to release cycle of 2023.11). So in 1-2 months we may finally get some more info.
 

sixonekevin

Member
All of this being my personal opinion and recommendation...

I think it can be a good idea to reduce the current amount of delivery to increase the quality.
However, this could lead to people losing interest in the engine. The delivery of fixes and new features is what normally keeps people interested in the engine. It's... a tricky balance.
On Android there are already behind in the Android Studio version and supported API version (in the required SDK it recommends up to API 33 and API 34 has been already released for some time).
Feather still has some annoying warnings which need to be fixed.

I think there is no obligation to make monthly releases, and each 2-3 months should be totally OK (unless a critical bug has been identified).
It would be great to have a Beta one month in advance of a Stable for example, which gives some time to fix any critical issue found.

For example, a year roadmap could be (always publishing the last days of a month):

Jan: Beta
Feb: Stable
Mar; Nothing
Apr: Beta
May: Stable
Jun: Nothing
Jul: Beta
Aug: Nothing
Sep: Stable
Oct: Beta
Nov: Stable
Dec: Nothing

This ensures that normally there is one month with no releases at all, and, in the normal month of vacations (Aug and Dec) there are no releases done.
FWIW, YYG is already very flexible with the “monthly” release schedule depending on what else is going on, eg if bugs found in the Beta are still being sorted out or in the case of this thread where they’re focusing on an LTS update. IIRC we only got five major monthly versions so far this year (1, 2, 4, 6, and 8, not counting minor updates) and I’m assuming with the next one not coming until November that will be the last one for this year.
 

Alice

Darts addict
Forum Staff
Moderator
Yeah, if YYG knows about some extra bugs to iron out, they'll rather delay the release by a few days than rush it so it's within the target month (like with the 2023.8, which was released at the start of September).
If severe bugs still make it to the monthly release, that's usually because the bug wasn't found during the beta phase, not because the release was rushed regardless of the known bugs.
 
Top