[Off-Topic] Backport fix to NAV 2018

[sgiordy]

Hello,

I've opened some issues that have been marked as "solved" but one of them was rejected because affects only NAV 2018 RTC. Other users here have their issues rejected for the same reason; other users again reclaim about solved fixes in NAV Cumulative Update, but the answer is: "there is no backport about these fixes, please open a support request through Partner Central".

Are you sure that you are doing the right thing?

Are you aware that most of the bugfix here are done by experienced partners with NAV 2018 version?

If you don't backport the same fixes also in NAV Cumulative Update through this GitHub repository, will be soon no more interest by anyone in contributing this cause.

Because we all aware that the future is D365BC but for now we are giving away our expertize to you, and you have to respect our time.

S.

[kalberes]

Hi, We have a Customer Support & Service team with Escalation Engineers in charge of verifying and delegating request for hotfix issues to us on released NAV products. And a Sustained Engineering team providing hotfixes or delegating the issues to us if it is reproducible on the current release. We cannot just backport whatever we want even if it makes perfect sense. Things have to follow certain processes, validations, documentations etc. This is why for the released Nav 2018 all issues have to go through the CSS team as it has been done on all other releases starting from NAV 3.70.

[sgiordy]

@kalberes I don't ask for a raw backport of all fixes to NAV 2018. I demand that the time that is spent here, is used also for NAV 2018. You can't require from us to open issue here and also in Partner Central, following two different cases, two different support team. It does'nt have any sense.

See these issues for example: #1654, #1478, #1342 Are all platform issues, not application issues. Serious issues that affects client and development behaviour. I hope that your Customer Support & Service team with Escalation Engineers will monitor and backport ASAP these fixes.

S.

[BertDeTemmerman]

1806

[sgiordy]

1650

[sgiordy]

1286

[dtacconi]

Ciao sgiordy

GithHub is a social repo where anyone can kick in whatever question in the issue channel related to Developer Preview. There is no SLA, no guarantee you will be answered, etc. It is a social hub (like e.g. Yammer – same story -).

The main page of the repo has this disclaimer: “Note that for issues related to Dynamics NAV, please use the support channel - see this FAQ entry.” The FAQ has a full entry about issues related to NAV 2018: “NAV 2018 issues This GitHub repository is dedicated to handling issues and feedback for the latest Developer Preview releases of the AL development tools” Moreover, whenever you try to log a new issue you get the following reminder: “Use the latest Developer Preview release both the server part and the AL Language extension in VS Code”

And yet – unfortunately yes – NAV 2018 issues continue being logged here and, as per typical Microsoft policy, all versions naturally in Mainstream support has to be redirected to CSS that will file a RFH (Request For Hotfix) or CR (Collaboration Request) to back port to version in Mainstream support.

What might typically happen, is that all the GitHub entries related to fix bugs in Developer Preview have been included in the product until NAV 2018 General Availability (GA). From that moment on, a new internal branch has been created for what now is Business Central (D365BC) and from that moment on all the new GitHub reported issues and events nomination will only be added to the “new” Developer Preview. In Fall 2018 you will have a brand new On Premise version.
That version will contain all the events added and bug fixes and features introduced in Modern Dev until it is cut (GA). From that moment on, a new branch will be created … and so on, an so on.

One very important thing worth to be mentioned and tattooed well in mind. The request for back port application events is typically accepted (exceptionally discarded – I still have to see one, honestly -) but if you want an AL Extension (VSIX) bug fix being back ported this has to be triaged and normally accepted. If you ask for a Feature Enhancement that is with Developer Preview and not in the version on the Mainstream Support then this is a no go. Why? Because of this is a product enhancement. Like e.g. in CSIDE when there have been added the Synch Schema For All Tables with NAV 2015 (just the first example popping up in my mind). This will never be backported to NAV 2013 R2. And nobody asked, since it was just a new feature introduced for that specific version.

All in all, then, if you have a bunch of Events nomination and/or VSIX bug fixing that have been already added in the Developer Preview and you want to have them back also with NAV 2018, feel free to create a support request for each of this.

[bwdeleeuw]

@dtacconi

Your premise is that, because of the yearly release schedule of NAV, we should not expect new functionality before the new version is released. However, because of the introduction of Business Central, we are now seeing monthly releases of not just hotfixes, but also new functionality to the product. The problem here is that Business Central on-line gets monthly upgrades, even though there are only relatively few using that variant. Meanwhile, on-prem (current NAV 2018), has to wait 12 months to get upgrades, even though there are millions of users using on-prem versions of NAV. Now I'm not advocating monthly upgrades, but quarterly or bi-annually would be a better situation. Before this latest announcement, there would have been a release of NAV 2018 R2 this spring, which would have alleviated some of the hurt, but now that that is cancelled, we are once again having to wait a full year before we can use the new functionality.

I think the channel has a hard time understanding why Microsoft is choosing to neglect their large and established customer base in this manner. I know I have difficulty explaining that to my customers. They feel that Microsoft insists on trying to push their customers to the cloud, as they have tried to with CRM, and with Office 365. The market is just not ready for it, and will start looking for alternatives, and Microsoft ends up having to scramble to release an on-prem version for their products, as they have done with CRM and Office.

Having said that, I am not opposed to the cloud, and we use cloud extensively as a company. Our customers however, mainly large equipment manufacturers and job shops, have deliberately located themselves in areas where labor is cheap, and internet infrastructure is problematic, and they have no choice but to implement a on-prem solution.

[sgiordy]

Ciao @dtacconi

please do not misunderstand my requests. I'm absolutely aware about D365BC, NAV 2018 and product lifecycle. I don't have any problem with cloud or on-premises version.

But I want to strongly report that now the expertise that allows you to improve D365BC come from NAV 2018 and from some partners like us that started with the new development environment.

What we have to do with new projects? Obviously we started to develop in new mode! What we have to do with existing customers that we want to migrate to D365BC? Obviously we started to convert the code!

Waiting for D365BC, what we have to do with these bugs? Have you followed the issues? Error with user preferences, error with decimal fields, error publishing app, error with report...

You think that us can work in this way?

I have no problem opening the same issues in Partner Central if you guarantee me that these issue will be considered. Because the last time that I've opened an issue in PC your colleagues wasted my time asking tons of proof, screenshots, demo database... with few or nothing result.

I think that will be more productive that one of your infinite human resources monitors this repository and reports and elects some issues to be backported.

Thank you S.

[StanislawStempin]

Thank you for the feedback. We are aware of the differences in the GitHub support process for preview releases vs regular support process for the released versions. We are discussing what we can do to streamline the process of opening and auto-accepting support cases when a corresponding GitHub issue has been already accepted/fixed by us (product development team).

I would also like to say that we greatly appreciate all the product feedback that you and other partners are providing through GitHub. This is very helpful for us in the development of the latest version but it also helps uncover critical issues in the released version and we are committed to fixing these as well.

An important thing to remember is also that On-Premise will be getting 6-monhtly releases so all improvements made to the latest versions will become available On-Premise.

[sgiordy]

1978

[sgiordy]

1260

[sgiordy]

Today I have opened many Request For Hotfix into Partner Source, one RFH for every GitHub issue. If is not a problem please maintain alive this issue so it's more easy to track the requests. I have opened RFH only for platform related issues; for function expose and event request we are autonomous modifying the standard code. Thank you.

[GreatScott000]

Okay, might be a dumb question but how to I open a request for hotfix for NAV2018 and NOT use up a support incident. Where do I need to go?

[dtacconi]

@GreatScott000 you must open a Support Request through the typical support channel (PartnerSource). CSS Engineer will evaluate your repro steps and if marked as an issue to be mitigated, CSS Engineer will escalate this request as RFH (Request For Hotfix). Give it a spin, bud :-)

[GreatScott000]

Okay but why do I have to use a paid support incident for a beta tool?

On 17 Apr 2018, at 16:24, dtacconi notifications@github.com wrote:

@GreatScott000 you must open a Support Request through the typical support channel (PartnerSource). CSS Engineer will evaluate your repro steps and if marked as an issue to be mitigated, CSS Engineer will escalate this request as RFH (Request For Hotfix). Give it a spin, bud :-)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[dtacconi]

@GreatScott000 if CSS Engineer evaluate that this is an issue that needs to be amended then you will not be charged nor decremented of any Support Request. This is how Support Request channel works since decades :-)

[sgiordy]

Thank you @dtacconi

1650 and #1286 has been backported to NAV 2018 CU5

[sgiordy]

Many thanks to @dtacconi

1654

1478

1342

1978

1260

Will be backported in the upcoming NAV 2018 CU6.