Construct LTS version

[KhaledFelfal]

Reviewed guidelines

• [X] I have read and understand the suggestion guidelines

Checked for duplicate suggestions

• [X] I checked for existing similar suggestions

Summary

I am writing to propose the introduction of a Long-Term Stability (LTS) version of Construct, specifically as of version r388.2. This request stems from the recent transition from addon SDK v1 to v2, which, while aimed at ensuring future project stability, limits the capabilities previously available and necessitates the porting of all addons to the new version.

The implementation of an LTS version would serve as a legacy system, preserving the functionality of SDK v1 and allowing for the continued use of existing addons. This version would not introduce new features but would be maintained with critical bug fixes and compatibility updates, particularly those related to export services such as the Android, Cordova, and iOS compatibility updates, and others. The objective is to keep our current projects exportable at any time with up-to-date APIs.

It is important to note that this concept is not unprecedented; GameMaker already offers an LTS version, demonstrating the viability and benefits of such an approach. The LTS version would be discreetly available to advanced users via a specific link, ensuring that it does not fragment the user base or the addon maker community. Moreover, as some addon makers are considering departing from Construct due to the new limitations, the LTS version could provide a compelling reason for them to stay.

The proposed LTS version would cater exclusively to advanced users who opt-in, fully aware of the responsibilities and limitations of not transitioning to SDK v2. This delineation ensures that educational and hobbyist users can continue to enjoy the safety and stability of the standard Construct platform with SDK v2, while those requiring the extended capabilities of SDK v1 can do so without compromising the integrity of their projects.

The introduction of an LTS version of Construct as of version r388.2 would be a mutually beneficial solution, aligning with the needs of a diverse user base while allowing the development team to forge ahead with innovations in SDK v2. I believe this proposal represents a win-win scenario and earnestly request your consideration.

Possible workarounds or alternatives

Currently, none. As some addons can't be ported to V2 at all.

Proposed solution

An LTS version as of r388.2 on a link like: editor.construct.net/lts or editor.construct.net/legacy

Why is this idea important?

So that we can ensure that our current projects can be carried into the future. I'm one of those working on a game that uses multiple addons. And I need to ensure that in 5 years I can still update my game with all the addons used.

Additional remarks

No response

[JeFawk]

Good suggestion, thanks for writing this. We barely change versions nowadays since our projects are in an advanced development stage. Even though C3 has great backwards compatibility, there is always some fix we written a workaround for, or something else that requires us to do extensive full game testing after an update. The bigger the project, the more this becomes unfeasible for us.

editor.construct.net/legacy sounds closer to deprecated, I would prefer /lts

[alvaromartmart]

Well... LTS usually stands for Long Time Support, which has very different implications vs. what you're suggesting 🤔

[KhaledFelfal]

Well... LTS usually stands for Long Time Support, which has very different implications vs. what you're suggesting 🤔

The name itself doesn't really matter, the suggest is what matters here.

[AshleyScirra]

The key question here is: what would the LTS release schedule be?

I think it would be relatively straightforward to do an annual LTS release - i.e. an LTS release is supported with essential compatibility updates only for one year, and then a year later it stops being updated and is is replaced by a new LTS release based off the latest stable, etc.

However if you wanted something like new LTS releases every year each supported for 5 years, that means in the end we have to maintain 5 releases in parallel in the long term, which might get pretty complicated; if it takes a lot of time, that comes out of other maintenance, support and feature work that could be done instead.

[JeFawk]

I would think 1 year support is too short for people that would benefit from an LTS version. I believe those kind of developers have some serious long-term projects (I know I do...) that couldn't be finalized within 1 year. From the top of my head i'd think at least 3 year support (though our current project is finished only roughly 10% after almost 2 years of full time work of 2 devs with occasional help from others).

Also having an LTS each year with such long support is not feasable, I'd think every 2 years or so. Some reasonable compromise must be made.

The only reason we've updated was for bug fixes, not features. Features are great but we're doing fine with what C3 has. And each update we had to spend a decent amount of time to remove workarounds, fix other things, etc. Pretty impressive it works though unlike other game engines.

[KhaledFelfal]

@AshleyScirra Originally, I was thinking an LTS release every time there's a compatibility update (Like these listed in updates notes)

Having these updates released annually could be problematic as new versions or requirements could be at any time.

is replaced by a new LTS release based off the latest stable

No, the idea behind an LTS is to still be able to use Addon SDK1, so the LTS version should stay on r388.2 FOREVER just with compatibility updates and critical bug fixes.

[AshleyScirra]

It's infeasible to keep supporting one version forever. Eventually we will have to stop supporting it. As far as I'm aware nobody else in the industry supports LTS versions forever - everyone has some schedule of eventually retiring old LTS versions and introducing new LTS versions, sometimes with overlap between them. The question is what schedule is being proposed here.

[KhaledFelfal]

@AshleyScirra

My goal is to be able to use SDKV1 for as long as possible. For example, Unity still offers an LTS from 2017 (7 years ago). It's out of support yes, but we can still use it. So probably a support for Construct's LTS for as long as possible then drop it but make it still usable? (At least we can manually export ourselves) Because for example, you can't use R280 which is 2 years old - from what I've tried - (https://editor.construct.net/r280).

[skymen]

IMO an LTS version every year that receives compatibility updates would be great but there should also be a small rollover period where two LTS versions are supported so projects can take the time to update from one LTS to the other and not have to worry about losing compatibility during the process.

Would it be feasible to have a yearly LTS with 2 years support? So you wouldn't have 5 LTS versions to support at the same time but 2?

Or alternatively, a new LTS version every year and a half or every two years would also be ok IMO if that means each individual LTS can get a slightly longer support period, and a long enough rollover period where both versions are supported.

TBH the rollover period length should depend on the actual demand for it, but the demand won't exist until an LTS version exists and nears the end of its cycle.

[JeFawk]

I disagree with correlating the rollover period length with demand for that LTS version (unless there is data that nobody is using it). It would help us to know a specific timeframe in which an LTS receives support. Having a set number of days per LTS version helps with planning the project's development cycle.

[AshleyScirra]

For example, Unity still offers an LTS from 2017 (7 years ago). It's out of support yes, but we can still use it.

Every past stable release is out of support, but you can still use it. The point of an LTS release is that it still receives some minimal but essential updates.

I think an LTS release just before dropping support for Addon SDK v1 would be a good way to ease the transition, and it's probably a good idea in future as well. (Note however we are talking about supporting an LTS for an additional period of time, not forever.) My preference would be for an annual LTS release, but supporting it for 18 months, so there is a 6 month overlap to the next LTS release. We could probably stretch that to supporting for 24 months, but with our resources I don't think I'd want to go further lest the maintenance overhead becomes too much.

Another question I have is: what time of year would it be best for an LTS release to come out? If a lot of games tend to be published around a particular time of year, then we'd probably want to time things to cover that with an existing LTS - we wouldn't want to end up with a schedule which drops LTS support just before everyone publishes.

[KhaledFelfal]

@AshleyScirra

Every past stable release is out of support, but you can still use it.

So r388.2 is here to stay, Great!

My preference would be for an annual LTS release, but supporting it for 18 months

I agree with that.

what time of year would it be best for an LTS release to come out?

Charts like this and this show that May and June have the least game releases overall. So, it's best to have a new LTS in May or June.

[skymen]

My preference would be for an annual LTS release, but supporting it for 18 months, so there is a 6 month overlap to the next LTS release. We could probably stretch that to supporting for 24 months, but with our resources I don't think I'd want to go further lest the maintenance overhead becomes too much.

That's very good IMO

what time of year would it be best for an LTS release to come out? Charts like this and this show that May and June have the least game releases overall

I agree that for me, the summer is usually when there is the least activity. Unity and GMS seem to do LTS as the last big yearly release since they have their release schedules tied to quarters. It might not make sense for Construct, so agreed that during the summer seems like a good idea.

Alternatively, if you have a big new feature planned for somewhere around summer, (like scene graph, timeline, Addon SDK V2, 3D or similar) you could have the LTS be the version just before it, so you don't give LTS to a release that would benefit from refinement that might happen in the following year, in which case you would have to backport a lot of fixes or leave it with a big new feature that's half finished.

[TackerTacker]

I think LTS versions are a great idea, not only for developers to be able to lock their environment down more safely, but I think it also gives Scirra more freedom to do necessary breaking changes in order to fix technical debt, and update long standing issues in regular intervals.

Based on the fact that these LTS versions would be mainly for serious projects that can take quite a long time to finish, and Scirra can't maintain a bunch of LTS versions at all times, my suggestion for an LTS schedule would be to release a new LTS version every 2 years and support each version for 4 years. This way there are never more than 2 LTS versions and 4 years should be enough for most big projects.

[AshleyScirra]

We are planning to make LTS releases in future. We will begin with a schedule of annual releases with 18 months of support each. We have completed some restructuring of the codebase to better facilitate long-term maintenance. There still need to be some changes to the website release system to facilitate LTS releases. If we can we will try to make the next stable release an LTS release so we can get used to the process in advance of another LTS release a year later, which will be the last release supporting the Addon SDK v1, which will then have 18 months of support (extending support for the Addon SDK v1 to a total of another 2.5 years). However the exact timing of the first LTS release is subject to change as there is still work that needs to be completed to support LTS releases.

[KhaledFelfal]

I do think that this is awesome, thank you for your valued cooperation!

[AshleyScirra]

Our first LTS release r397.3 is now available. We may need to revise how the process works over time as we are just getting started with LTS releases and we'll also be learning ourselves how the maintenance works out - but as we have now made our first LTS release, marking this as shipped.