messengerspot.blogg.se - Monosnap stable release

#Monosnap stable release how to
#Monosnap stable release manual
#Monosnap stable release archive

I can understand that your policy is to not target pre-release versions, but it sounds like you didn't even have a separate internal branch created beforehand to work on compatibility/migration I may have misread, but it sounds like that process didn't begin until the day after ASP.NET Core 2.0 launched.Īlso, there appears to have been ample time to notifiy subscribers of potential compatibility issues with the current release version of the Core wrappers, but this does not appear to have happened (again, my apologies if something was sent that I overlooked).

#Monosnap stable release how to

be aware of how to set up a local nuget package repository to host this internal build (not documented)Ĭonsidering that this is coming on the heels of (at minimum, using official release date) a 10 day wait for the 2.0 compatible version, or as an unexpected "gotcha" after migrating an existing application to ASP.NET Core 2.0, you are undoubtedly going to be dealing with a number of confused and frustrated customers.īased on the thread history, this issue was identified during pre-release for ASP.NET Core 2.0, and has been on the radar for several months.

#Monosnap stable release archive

be aware of how to obtain the nuget package archive from within the internal build (not documented) be aware of how to obtain internal builds (not documentated, but probably only an issue for newer licensees, in light of the recent trend towards delivery via package managers) be aware that an internal build has been released to correct these specific compatibility issues be aware that Telerik's nuget documentation is incorrect (the documentation discrepancy could lead one to assume that no internal builds exist)

In order to resolve or work around this issue, the developer would need to:.

As far as I can tell, there isn't even a pinned forum post for this topic. There has been no mention of this in product newsletters, support alert emails, blog entries, website notifications, etc. I was personally unaware of these issues, prior to upgrading my application to ASP.NET 2.0.

lack of advanced warning/alert/notification.

conflicting behavior/practices between teams responsible for components/products, even though both components are needed.

misleading, incomplete, or inaccurate documentation.

My apologies if I have overlooked something, and please correct me where wrong, but this is how I see the current situation, as a customer: In your online documentation for the Bower Packages page (), the phrasing used is almost identical to what is used on the nuget packages page, yet the behavior is completely different.Īs a result, your product documentation is out of sync with the your support responses/messaging, and the deployment practices for the MVC and Core wrappers is not consistent with the practices of the underlying Kendo UI Core/Professional product. To add additional complication/confusion, internal builds ARE currently available for Kendo UI via the bower package manager.

#Monosnap stable release manual

This newer approach makes perfect sense, unless you aren't given the ability obtain all the necessary builds, and are forced to switch to an undocumented manual process. The ASP.NET Core wrappers documentation appears to be steering users away from the older approaches (via VSIX or manual install), and focusing solely on installation via package managers. The Getting Started documentation mentions an option for manual installation of the clients-side components, but not the wrappers. This certainly seems to indicate that registered users should expect internal builds to be available on the private feed as pre-release packages.Īdditionally, your documentation makes no mention of any other methods for obtaining internal builds of the ASP.NET Core wrappers, or where to obtain the.

Official releases, service packs and internal builds of UI for ASP.NET MVC are available for registered users. I would strongly suggest that you need to either revise your policy regarding nuget internal builds, or at the very least revise your online documentation.Īccording to the online documentation for your nuget packages ( ), the very first line of the the description states the following: Bozhidar said: Since only official releases are uploaded to nuget, in order to test the internal build you have to use it from a local package source.