Aspose release velocity is impressive, but it’s a challenge to keep up. This week we upgraded from version 21.x to 23.2.0 on 6 Aspose.Total Java libraries. There were 4 incompatible changes that required source code modifications. All of them were in APIs, which are supposed to be immutable by convention. I’d like to understand Aspose philosophy on making such incompatible changes, because spending time chasing compilation errors after upgrades only makes me want to delay my next upgrade or find a better replacement.
- SheetRender.getPageSize changed to SheetRender.getPageSizeInch. Seriously?!
- getAnnotationType result changed from int to AnnotationType enum. Why not introduce a new one? Every code change has a risk associated with it.
- SlideOrienation replaced by SlideOrientation. Let’s see how many people notice what I’ve actually written (hint: check the spelling). If you have misspelled an API, document it, but DO NOT introduce an incompatible change just because the old one was misspelled!
- Obsoleted FixedPageSaveOptions.PageIndex because of the new API. New API is good, but don’t touch the old one. Make it slow, trigger warnings, etc. but do not force users to have to revisit their code.
I’d like to suggest to the Aspose designers to keep in mind scalability. As an operations person, I deal with thousands of components, both OSS and commercial. I fully support the need for upgrades to address security vulnerabilities or new functionalities. But when a component vendor makes my life difficult by making every upgrade a chore requiring multiple exchanges with developers located all over the world, that vendor does not get good marks for ease of use & upgradability. Instead, it makes me want to find a replacement that is easier to deal with on upgrades.
@pskoskiewicz,
Generally, we announce in the relevant docs if some APIs are added, obsoleted/removed or changed. We announced it and obsoleted SheetRender.getPageSize(int pageIndex) method in the release notes document of Aspose.Cells for Java 21.10.
We replaced it with SheetRender.getPageSizeInch(int pageIndex) method to make it more meaningful. We try to adopt better naming conventions so APIs are more readable and consistent across the board. We are sorry if it disturbs you a bit and is incompatible. We do not rename APIs often but once in a while if it is really compulsory. Anyways, we apologize and will try to avoid such practice as much as we can.
We will get back to you soon and provide details regarding other APIs you highlighted.
Please note that I’m not complaining about the lack of announcement or documentation of these changes. I think public APIs should stay as they have been announced, warts and all, and new releases should focus on new additions. Changes to old APIs should really be considered an emergency. IMHO, 
@pskoskiewicz,
Thanks for sharing your suggestions and concerns.
Please note, the old API SheetRender.GetPageSize(int pageIndex) returns pixels in .NET but returns points in Java. We thought it was confusing for the users, so we replaced it with the newer API SheetRender.GetPageSizeInch(int pageIndex), which returns inches (unit) in both .NET and Java to exhibit uniformity and consistency. Anyways, we understand your concerns/difficulties but you know sometimes incompatible changes are necessary and inevitable in rare cases.
Thanks for your understanding!
@pskoskiewicz In Aspose.Words we keep old API marked as obsolete for a year before removing it. Unfortunately, evolving API and adding new features sometimes requires changes in the public API. But we always try to avoid breaking changes in the API.
@pskoskiewicz,
While developing Aspose.Slides, we also adhere to the common strategy in Aspose products, keeping methods and properties of classes in the API for a year after deprecating them, so that users have enough time to make the necessary changes. We try to avoid changes to the public API whenever possible. We apologize for any inconvenience.