The good and the bad with the current Defold releases

The only issue I’ve had with a Defold release is when spine was removed, I thought that if I didn’t update then I would be able to continue my project without needing to get the dependency. This didn’t work and lead to a lot of confusion when my game built successfully but wasn’t playing properly.

Would it be possible to have a warning message popup if you attempt to Bundle a project letting you know that your Defold version is more then 6 months behind or if a breaking change has been released between your current version and what the build servers support? It could be a “Would you like to continue?” style message so users can continue if they do not think they are impacted

1 Like

Maybe I am doing very simple stuff but I’ve never had any problems with this. I don’t know what next-level stuff everyone else is working on!!

This would be a great idea.

Oh, hello. I really wasn’t expecting one small paragraph in my big postmortem to spin out into a separate thread. It wasn’t really intended as feedback, certainly not a request, more just a personal reflection, but sure I’ll try to expand on it.

Firstly please bear in mind that I’m talking about 6 years’ worth of Defold updates. Breaking changes may be rare, but there have been several over that kind of time frame. Also updates may now be monthly but they used to be fortnightly.

The point I was trying to make is that it isn’t clear what version of the engine the engine’s developers expect me to be using, so without any other indicators the answer is always ‘latest’. With Unity LTS there is clear communication: if you want stability use an LTS version, if you want new features use what they call ‘tech’ versions. Also, LTS versions have a clear expiry date of 2 years, after which they stop being supported but remain available. There is a clear strategy here that they explicitly describe and recommend: when you’re starting a multi-year project, start on the latest tech release and follow that, settling on whatever the newest LTS version will be that comes out during the length of your project. If you’re starting a project that will take a year or less, just use whatever the newest LTS version is at the project’s start.

Updating the Unity version of a project is a big deal, it can take days of work. But you know that going in and you only have to do it once or twice a year, so all the time spent on it is batched together. Plus they have update guides detailing all the breaking changes, so you don’t have to read thousands of largely irrelevant patch notes.

With a monthly and especially a fortnightly update schedule, there is a constant background pressure to update. Especially for an irregular hobby project, there will practically always be a new version of the engine out, and I don’t know if I’m expected to update or not.

I did eventually. Was I expected to, supposed to? I don’t know, it didn’t feel that way. Will problems arise from a project remaining on an old version of Defold? I don’t know, presumably.

Updating the version of any engine any project is running on has risks and costs. Things that are relevant to your project may be added, removed, intentionally changed, unintentionally changed, or broken. Some of those risks can be mitigated by spending more time on updating your project, which is the cost. You can take a chance and update blindly, or you can be thorough and read all the patch notes between your current version and the latest, noting all the risks relevant to your project and the things you need to check or do post-update to verify or fix them. Clearly this takes time, and it takes an increasing amount of time the longer you wait to update. Probably you could do most updates blind without issue, but you need to be doing so regularly, because otherwise when an issue does eventually occur you’ll have a hell of a time identifying where it came from if you did one big blind jump.

Btw to make my life easier I ended up having a defold-version.txt file in my project under source control so that I know what version of the engine a project is using and can see the history of what versions it used before.

Project last updated to:
Defold 1.3.0
Released 7th March 2022
https://github.com/defold/defold/releases/tag/1.3.0

At the time of release, Curious Fishing was on a version of Defold 6 months out of date. Is that a problem? I don’t know. Will that be a problem when I open the project 2 years from now? I don’t know. It would have been a year out of date but there were fixes I had requested in that version so I needed to update to it.

5 Likes

From our side of things, we strive for a process where it is safe and recommended to update whenever there is a new update.
Just like there are safe editor updates continuously (between the Defold releases).

We still consider breaking changes an exceptional event, and we don’t do it lightly. We only do it if it can be considered a necessary bug fix, or that it will help us enough by removing old problems from within the pipeline/engine so that it is worth it.

Some of the changes in the past have been more manual upgrades. In the future, we will look more into automatic migration, so that it will be even less of a hassle.

4 Likes

This is another communication difference. From the maintainer’s perspective there may be a difference between the engine and the editor but from a casual user’s perspective there isn’t. Whenever I’ve said ‘engine’ above I am talking about the combination of the engine + editor. If I open Defold and it says an update is available, that’s what I’m talking about.

I am as well. Defold as a whole is the product.

What I was referring to was that internally, we have two ways or working with updates.
Smaller (safer) changes are done continuously, on a (possibly) day to day basis (if there was a change). Larger changes are done on a montly basis.

The larger changes are riskier, and needs more thorough testing (hence the Beta period), but ultimately, it should still feel safe to update to the latest version.

Keeping the engine up to date just isn’t very important to me. I stick with what’s been working until it doesn’t - mostly because libraries are kept up to date with the engine.

I have a second computer that I use when updating. I update the engine on that machine and build my current source. If it works, I update my primary dev machine.

So far, I haven’t felt the need to update more often than once or twice a year. The much lower hassle and fewer interruptions are worth postponing updates.

2 Likes

No, definitely I didn’t mean less features! :smiley: More features is definitely the way for Defold, same as with putting things into extensions, these are all good things, just needing more care to please most of the devs :wink: Thing like a ticket Bjorn created is like a part of this I believe :wink: Also things helping devs identify issues that might appear after upgrading, something like warnings in console log, that some function is deprecated, changed etc like e.g. in case of draw3d() function

Always use last, or few releases before last.
Does not have any problems:)

For me big problem can be 1.2.n → 1.3.0.
Spine breaking change.
I have some old prototypes and project with old spine, and when i want to build it will be very complex.(i do not need it now but in future everything possible)

So if you can support that breaking changes defold version in build server more than 6 month. It can be usefull in some cases.

In other cases, imho it is easy to update engine version to latest.

3 Likes

The engine updates are not frequent and not tiresome. I think the original issue is about updating the editor which can update quite frequently and with no changelog. Perhaps displaying a popup like this:

Engine version: 1.2.4 - up to date
Editor version: 765432 - 765438 available

would clarify the confusion and make the decision whether to update or not clearer. Not all people have fast internet or even fast computers, just unpacking stuff can take some time.

8 Likes

I’ve had some issues here & there with updates. Typically upgrading on Windows was seamless, but once deployed to Android, on rare occassion, crashes would occur in either the engine or (more typically) native extensions.

Luckily, the Defold team is exceptionally fast at reviewing our bug reports and fixing issues!

In an ideal world, I’d have the time to upgrade to each beta version and do on-device testing before the version reaches final release. Until then, it’s not a big problem for me to delay releases by a few days while waiting for the engine or native extensions to be fixed.

I’ll add my +1 to the request for having more details in the “update is available” dialog. A changelog or link to view a changelog would be really appreciated.

7 Likes

How common are hotfixes such as this?

Are hotfixes always announced, and what kind of bug would trigger a hotfix?

A post was merged into an existing topic: Supporting non english languages and RTL languages

Yes, we always post about these on the forum. It happens rarely (probably at most once per year).

In this case it was an infrequent crash on 32 bit Android devices due to an off-by-one error in long Lua bytecode diffs. The workaround was to publish one 32bit and 64bit APK, but that is not always possible to do on Google Play, and with enough installs the issue had a significant enough impact that it warranted an immediate fix.

2 Likes

Didn’t 1.3.5 and 1.3.6 have hotfixes too? Or are these a different category?
I would prefer if there were new forum topics about these, as many users won’t follow threads for released versions.

@AarrrBee you are absolutely right. My mistake.

We will make sure to do this going forward!

2 Likes

I would love to suggest, on more beefy new features, like for example the new texture manipulation api in the works, to add some nice examples with different use cases when released (and here the community can help)

1 Like

Is it possible to “freeze” old Dockerfiles? If someone were to request a build from a 1-year-old-Defold they could get a build with older SDKs. Would it still ran correctly? They would not get latest and greatest SDKs if they were on old version, it would be their choice.

We’ve chosen the 6 month cutoff point for extender support since that has felt pretty natural for development.
We don’t want to support too many versions on our end since the support burden increases a lot for each SDK.

Also note that that the server is open source, and you can setup your own server to support the SDK’s you want.

2 Likes

Oh I love defold for this. Unity was a PITA in dealing with which version do you want to use.

Defold is 100% on the right track IMO.

2 Likes