13 Replies Latest reply on Jun 22, 2020 7:44 AM by _miki_

    Better communication of breaking changes

    _miki_ Novice

      Hopefully, I haven't overlooked any accessable documentation, but according to my researches at Aurea Support Portal / Works / etc there are no documentation or post, which would introduce the breaking changes made by enhancements or upgrades of dependencies. I'll go on with the example of update.server (Batch Processing Windows Service):

      • update.Server.exe --help outputs new command line options, which I've never seen before, but could be useful in the future (e.g. --execute, I guess at least, that I could start a predefined job manually) - no documentation
      • I've found the configuration option "MaxConcurrentjobs" in a web.config upon reviewing a fresh installation (no upgrade) - the only documentation can be found here: CRM.ReleaseNotes_v10.2.0.pdf
        Remark: I'm not even sure if the mispelling of the word "concurrent" is intentional
        Remark 2: <MaxConcurentJobs>1</MaxConcurentJobs> or <MaxConcurrentJobs>1</MaxConcurrentJobs> - does not have any effect on the execution, multiple tasks are started and get finished almost in the same time - I might file a case if I have the time for it.
      • A new job execution model has been introduced, that means according to my experience: a separate update.server process is created for each job execution for the lifetime of execution - no documentation, but the main question is: is there a way to turn this behavior off in order to attach a debugger more easily? (without workarounds)

      This was only an example based on update.server, but that's always disappointing to find undocumented surprises after an upgrade to a higher version. I mean, there should be a better way for documenting new features than include a brief description in the Release Notes, which are only separately browseable and give only an idea, what should be expected.

        • Re: Better communication of breaking changes
          _miki_ Novice

          What about creating KB articles and reference to them in AureaWorks/Jive in order to make it more visible/findable for everybody? Not just for those who might inquired more information via Support Case. For example, if I've just received some documentation from the support team - maybe in the form of a new KB article, nobody will know about it.




          • Re: Better communication of breaking changes
            _miki_ Novice

            Hi Mael Forner,

            I don't know if you were the right contact person for this issue, but the subject of this post is the lack of communication, which also results in a higher demand on the support side, because those breaking changes, which have not been communicated well, are brought up as a support case due the confusion / faulty behavior. Compared to that writing a documentation or announcement to the developer (via Jive/Email) besides the release notes (which are much more for the mass) is a one-time demand, right?




              • Re: Better communication of breaking changes

                Dear Miklos Moricz,


                Thank you for your message.


                I am definitely the right person to contact for these questions. I already have contacted the stakeholders to look for a solution and have scheduled a meeting to explore the options. I didn't post any comment since I don't have right now a solution.


                The discussion will be focused on the opportunity of improving the publication of KB articles. Maybe we could provide a list of the recently created KB articles, or offer an easier way to consult all of them. Please note we consider that an access to the Support portal is necessary. Indeed it's essential to improve the relevancy of our Knowledge Base Articles through a machine-learning process.


                I will keep you updated next week at the latest.


                With my thanks for your patience.


                Best regards.

              • Re: Better communication of breaking changes
                bjn Novice

                Hi Miklos,

                regarding your "new parameters" while updating..

                In times of update.seven there was an "/update_to_check" -folder containing all files needing manual editing.


                Starting with AureaCrm I used to update our installations by:

                - renaming the current product folder and by appending the version number, eg: <xxyy>_11.8 <- this is our backup

                - then I start the installer for the product - which extracts it to the originating folder.

                - after that I use BeyondCompare or any other diff tool to merge the config files -> new sections, new parameters aso. (see KB 42864 !)

                - finally I merge custom files from the backup'ed <xxyy>_11.8 into the <xxyy> folder (where the new product files are).


                In the end I have a fresh installation folder (+backup) and also get rid of orphaned files from old packages.


                See KB:

                36666 CRM.server fails to process a To-Do with the following error: "Failed to get service IConfigurationSession"

                37065 better handling for configuration files during patch/upgrade

                42864 Newtonsoft.Json error while starting web after Upgrade to 11.4.0 or higher

                1 person found this helpful
                  • Re: Better communication of breaking changes
                    _miki_ Novice

                    Hi Bernhard,

                    thanks for sharing your approach for a clean upgrade!


                    Regarding to the KB references: those are exactly that articles arised from accidental discoveries: somebody was curious to install the latest update and bumped into a bug or shortage right after the upgrade. The initial motivation of this question was the fact, that upgrades might break working extensions or bring behavioral changes, which are disadvantagous from the technical perspective.

                    Certainly somebody will encounter them and create a support case, a Knowledge Base article is created finally with the instructions. This procedure could be theoretically prevented and time could be saved, if the developer who break with a convention or make a change with a huge impact, publish it in a separate channel for partner developers and technical consultants.


                    Conclusion: the originally proposed solution might be a good approach to create more KB's on demand, rather than trying to publish a precise static PDF document with all the informations.