Your’re describing the current process. I’m well aware of it unfortunately, and point to the issue in it.
I’m not talking about releases. We are fine with monthly releases, with more thorough testing to avoid regressions and etc. I’m talking about means of delivery for hotfix versions we constantly depend on. It’s a separate issue. As I explained in my previous reply, switching back and forth between NUGET and local .DLL in multiple projects in our codebase is very manual and time consuming process. For NUGET dependencies we use PAKET (https://fsprojects.github.io/Paket/) which is a very convenient and efficient tool.
From my previous reply, publishing hotfix versions with pre-release versions makes general users to ignore them by default, and at the same time enables easy access for consumes that expect the fix version specifically. It is year 2017, not 2007 and downloading and committing binary dependencies to the repo is not acceptable anymore.
Just to add more context. In our organization we develop a general reporting solution base on Excel workbooks as templates for reports. This means that the engine built using Aspose.Cells deal with various Excel workbook provides by end users. This constantly reveals bugs/issues in the library. Some of them we report to Aspose, for some we choose to implement workarounds in our codebase as a faster/easier option.
I think it’s in the best interest of Aspose as a vendor to receive timely reports for as many issues as possible. That means that the whole feedback cycle should be straightforward and seamless, so less time we choose to skip it. That begs for supporting tool, like. NUGET to make it easier to incorporate provided fixes.
Another area would be on the reporting side. In many organizations Excel files contain private data. It’s our case most of the time, but should be common I expect. In case of an issue we have to clean the file from sensitive data, but in a way that preserve the issue. Only then we can report the file to Aspose. In most such cases the manipulation cannot be performed by Aspose.Cells itself. So we have to do it manually in Excel (very time consuming, especially for large files). I think it makes sense for Aspose to develop a tool that assists in this area. Bare in mind, the most difficult bugs to catch during testing (on Aspose side) are the ones we observe in a wild dealing with numerous (sometime very complex) files of our end-users. It’s a pity that in many cases there is not way to transfer such issues to Aspose.
Please communicate my concerns to the tech team leaders, or let me know if we need to report it through the paid support channel for it to be taken seriously.
Thanks!
