The good and the bad with the current Defold releases

[britzl]

@connor.halford

One thing that was unclear to me was what version of Defold I was supposed to be using. Releases are very regular, mixing together both features and fixes. For an irregular side project, keeping up with releases took an annoying amount of time (until I abandoned doing so), and often led to subtle bugs or changes in behaviour. I prefer the clarity of the release structure that Unity, Godot, Blender and many other software projects follow, with key feature versions followed by stabilising Long Term Support versions. If you need or want the new features then you update, otherwise you stay on LTS and just receive bugfixes.

@Pawel

Also few good points for the Defold release cycle worth considering. I started having the similar problems with not being up to date sometimes and I think I’m very active though. It’s just, that if we might miss something or so, the new users and users getting back might have similar problems. Release note are great and have summaries, which is of course good, but what me and you are trying to emphasise here is a mixture of fixed and features and that the frequency of smaller features might be overshot and simply missed sometimes

@Mathias_Westerdahl

Not to hijack the thread, but it seems like something we should think about.
My problem is, I’m not sure you you mean here. Do you want more features or more bug fixes. It kind of feels like you don’t want any more features?
And number of breaking changes I would say is fairly low?
Which ones affected you negatively? And what could we have done better?
E.g. we have documented migration steps, or we do it for you (in the editor).

As for what we work on, it’s always a balance between the paid support, the open tickets (which you vote on), and things that we think is beneficial to the community (e.g. the RoadMap).

I agree with Mathias. I’d like to learn more about this feedback. We do roughly 12 releases per year (ie 1 release per month). The releases typically contain a mix of incremental improvements, new features and bug fixes. The releases should rarely contain breaking changes.

Personally, I’ve always liked this way of working. When something is done we ship it instead of holding on to it until The Big Annual Feature Release.

Good things about shipping stuff when it is done:

• Developers get access to new functionality as soon as it is ready
• New functionality gets tested by the bulk of our users when it is done (assuming that our users update to the new version)
  • This means that the cost of fixing issues is lower than if issues are discovered many many months after the implementation was completed.
• We do not have to maintain two active releases at the same time (LTS with bugfixes and Latest with new features AND bugfixes).

Bad things with shipping stuff when it is done:

• The impact of each release is much smaller than if all new features are released once per year.
  • Compare Defold 2.0 (wow!) with Defold 1.4.1 (meh!)

@connor.halford and @Pawel :

From your feedback it seems like there is a cost for you to always try to keep up with the latest version? Is this correct?

If this is correct then why are you not deciding to “lock down” your project to a specific version of Defold and never update from that version? Is it because of bugs with that version?