[Suggestion] Prepare apps for NextMajor

[fvet]

Whenever a new major BC version is released, we do not only increase the app version of our apps, but have to update the app.json files to reference the latest:

• Runtime
• Platform
• Application (+ update the version to the other MS or MS test app dependencies)

As we have 30+ repo's, this is currently managed by an Azure DevOps pipeline that applies these rules across all repo's.
Moving to github (multi-project repo) could simplify this task, as the number of repo's would be limited, so we could try to perform this in VS Code....

However, it might be interesting if MS could provide a (new?) github action that automatically prepares all app settings for the next major, by updating the app.json of all the projects in the current repo (maybe even without asking for any parameters, as these are known by MS). Application, platform, runtime could be changed via a Replace All in VS Code, although updating the dependencies for the MS apps might be more difficult to do so.

[jonaswre]

Hi, I've heard the request a few times already. But I could never really understand why. But maybe @freddydk could find the truth here.

So the runtime, application and platform are minimum versions. You technically don't need to update these versions to be compatible with NextMajor.

But there is a rumor going around that you need to increase the runtime to use performance improvements in the newer runtimes. (Even if you don't need any new features in code).

Is there any reason to still update these versions, even if you technically don't need to? We usually just update them in our apps when we want to use new runtime features.

If @freddydk answer is you should increase them then we need to change the way dependencies are resolved as well. We need to add proper minimum Version support not just grabbing the latest.

[fvet]

I'm fully aware that not updating these properties / increasing versions would not pose any problems when moving to the next major, as they are indeed just minimum versions.

However, as there's so much that changes with each new major version, we try to be as close as possible to the latest version and adopt new platform features whenever available. Being able to use the new barcode control, having access to the richTextEditor, use the newest AL features / new properties, ... forces us to do so anyway.

Internally, If we decide to release our apps for v23 and increase our own app version to 23.x, this implies a dependency to BC23.

In addition, the new major is also often a validation point to review any missing event publishers we've requested the past months and we adopt pending changes to use the latest application symbols.

As we're closely integrated with BC functionality, also new features / updated functionality (e.g. revised warehousing functionality, ...) forces up to increase the application version anyway.

Using the same application/platform/runtime when maintaining multiple apps just avoids some complexity. We've try to adopt the same principles as MS does, and it seems like each new (major) release, all MS apps are put on the same version as well (microsoft/ALAppExtensions@cbbeef9)

[freddydk]

@fvet (and Jonas) we should meet and discuss the best way AL-Go could help with this scenario.
I do have some ideas, but would like to get other peoples eyes on them.
Right now I am on vacation in the US (back Tuesday next week) - maybe we could sync at Directions in Lyon or on a Teams call shortly after that?

[jonaswre]

@fvet good points.

We have a different philosophy. We consider what's the minimum version we need for each app so we don't exclude customers that can't update like on SaaS.
But maybe your use case is a bit different in that regard. Our dependency forest is wide not deep. So if we update one App in the forest this doesn't mean we need to update all other apps.

But if Microsoft suggests to keep it updated we would gladly do that.
Im very curious to see if there are any technical benefits to updating, if you don't need the new features.

@freddydk I have some inputs. Maybe we could use Indirect Templates and a JSON Patch Format.

I won't be at directions this year. But I would love to have a call.