GPicora wrote:SFA wrote:GPicora wrote:Amazing, what about giving Mojave support on 11 when you had the chance as Mojave was release months before CO12, and don't push our arms to buy an upgrade each year?
G.
You could, perhaps, also suggest to Apple that they don't constantly make changes that stop older versions of your software suite working without an option to run just as they were.
I doubt they would listen.
Grant
Grant, Im a macOS and iOS software developer as well as photographer, and while is true apple make changes and enhancements on each release there is a huge beta period for us to test and fine tune the apps to have them compatible since day 1, well week 1 lets say. Plus there aren't drastic changes Apple makes that makes software unusable over the past of a one year, maybe this happens when a software ifs few years old and Apple drop support / depreciate some APIs or method calls, then your comment makes 100% sense. But My point is that I believe this strategy to submit C1 new software on November- December its aimed to force users to upgrade the last's year license in order to get latest OS support. As we well know Phase One drops supports of "current" version once the new version is released, hence making that "current" version not compatible with current OS.
There have been instances in the past where last minute changes to what is released in the OS compared to what was in late beta versions have adversely affected development work already undertaken.
I suspect some developers, as in the 'old' days, attempt to isolate their products from update changes as far as possible to avoid conflicts of that sort. But if one develops to take advantage of the very latest performance enhancements (to take one possible example of many) then isolating your application is probably not an option.
I think the timing of releases is simply something that makes sense in the context of when significant influences on your product come in to play and how you handle that timing if you have a relatively small development team supporting 2 operating systems and a number of external influencers (the camera and lens manufacturers for example but mainly the camera companies) who are working to their own marketing schedules.
On that basis one sees Apple and Microsoft significant updates in the autumn and often (notably Photokina years) camera manufacturer updates too (or at least announcements with availability follow later and spreading across worldwide markets over some month in some cases).
Plus Phase needs to provide support for its own product release schedule.
The potential, therefore, could be a release every month (or even more frequently) as product becomes available to test in production units rather than pre-production. I doubt users would really appreciate that. If you take the need to keep documentation up to date (to avoid complaints) and similar matters of administrative importance rather then image processing code importance, the overhead could be absurdly unsupportable.
I suspect that is what influences the timing.
As for supporting older releases but including new features of OS feature support - a tricky question.
I work with some non-image processing data analysis products of a commercial only nature and they will rarely attempt to retrospectively update older versions. If they had a multi-million dollar client on a subscription basis or a purchased licence with maintenance payments they might consider it I think, but only as a significant one-off special project. Such products are usually multi-user server based and therefore change options can be limited for the client as they balance the needs or limitations of multiple applications on their systems. Doing a deal on a "special" support arrangement may suit both parties if the price is right.
But these are not new issues.
One of the reasons that companies like the subscription approach is that once the client has bought into it they tend not to think about it much for a while. So the vendor either simplifies their support load (at least in theory if all goes well) by making sure user's systems are up to date (not so obvious as a option in the corporate world) and enhances their cash flow, removing peaks and troughs of earnings.
It's also quite useful as an easy way to convince people they are getting a 'good deal' by making the offer appear to be highly attractive and including a lot of facilities that users are unlikely to use but presents as a very generous offer. Mobile phone contracts can be strong examples. The value in the highest cost contracts would be incredible if only the phones could easily provide facilities to call and text and use data sources in parallel 365/24 and humans could use them for the same periods.
You very likely know all of this and understand the ramifications but other visitor here may not think in these terms.
On some of the matters that might be most contentious, camera support for example, there is the question of the mechanism by which camera specific profiles can be delivered. And potentially a sub-issue about control of intellectual property.
I have in the past used software that allowed people to define what they thought to be acceptable colour profiles and share the profiles individually without having to wait for a release. However RAW files still had to be recognised be an externally developed and supported RAW converter 'engine' and typically one had to wait for that to be updated and then integrated into a release before a successful file interpretation could be expected consistently. How long that would take was often a moving target. Sometimes it was quite quick. At other times really rather slow. Especially in one case where the developer closed down but released the code to Open Source about a year later.
My conclusion is that in reality for commercial reasons but perhaps also quite often for technical reasons, the 'new release only' policy is probably the only way to go in most cases. There may be some rare exceptions. Maybe 10,000 customers on perpetual licences paying 30% of full list price per annum for maintenance would be such an example. Pick any other number that one thinks might work.
Grant