You’re offline. This is a read only version of the page.
Microsoft Dynamics 365 Business Central is a fully fledged SaaS solution whom its On-Premise equivalent is following cloud rules. SaaS and On-Premise deployment are both based on modern lifecycle policy
Software lifecycle policy and on-premises updates - Business Central | Microsoft Docs
A Major version, typically live in SaaS for 6 months hence it will receive 5 updates before the next release is kicked in and the 3-versions-earlier is out of support.
To give an example, version 18.x (2021 W1) has been just released and 15.x (2019 W2) is now out of support. In October, version 19.x (2021 W2) will be released and 16.x (2020 W1) will be out of support. And so on.
Within the 6 months SaaS period, typically from update 1 (e.g. 17.1) to update 5 (e.g. 17.5), partner have 2 channels reporting bugs: SaaS (more proactive and fully telemetry driven) and On-Premises (reactive through Support Requests).
All platform and application bugs that are reported through SaaS channel are marked as Code Defect within internal repair items.
Platform and application bugs reported through On-Premise support channel are marked as Request For Hotfix (RFH).
Knowledge Base (KB) articles are reporting only reactive incident bugs while Code Defects are not listed.
Starting from update 6 (e.g. 17.6) onwards, the only feasible channel to report bugs is through Request For Hotfix (RFH).
For the reason mentioned above, then, up and included update 5 there will be a discrete number of Code Defects (typically the vast majority) that has been resolved in SaaS for whom On-Premise is taking benefit.
The only drawback is that these are not listed in the On-Premises Knowledge Base (KB) articles.
While this is not a problem within SaaS whom takes benefit of a continuous update, it could be relevant for On-Premises installations that might require a more frequent update or platform tests in staging environments.
Another important consideration between SaaS and On-Premise environment is related to Event Publisher requests through GitHub
Issues · microsoft/ALAppExtensions · GitHub
When developing, you might be in need of a specific Event Publisher whom to subscribe to in order to leverage your own private IP in the form of an extension. What is requested, then, is to file a request for publishing a specific event and wait for product group to uptake the request.
Typically, this takes a couple of months to be effective – depending on backlog and workload -. What will happen, then, if a request is logged one month before next major release?
Based on the assumption above, the request potentially could be added in the update 1 for the next major release. Product group does not accept backport of Event Requests since these are marked as Feature Enhancement and cannot be requested through the normal bug fix channel (in fact these are not bugs).
While this will not be a great problem within SaaS, thanks to the continuous update, it might be more important with On-Premise deployment where a major update should be required, within this scenario, instead of a minor update.
In shorts: planning Event Publisher requests should be done as soon as possible in order to have product group implement them once for all. And forever.
Share
Report
All responses (
Answers (
3,750
