Sorry about the breakages. There are deprecation warnings for most changes. If you were using the API, in principle most things should "just work." There's one big exception: when I have a missing method for new data types. Unfortunately, since this transition introduced a _lot_ of new types, missing methods are a very real problem, and this bothers me quite a bit. Happily, the rate of discovering those seems to be going down. Such issues should be viewed as bugs, and I am happy to fix them if you tell me what they are.
Where the problems come in is if your code was exploiting some aspect of the raw representation of images. In such cases, there is no way to achieve co- existence: the image either uses one representation or another, not both. So unfortunately it's not possible for me to maintain compatibility the way you seem to be asking for. In general, where possible I recommend trying to use the API in Images rather than digging into the internal representation--- that's your best protection against changes. In terms of fixing your current problems, the README spends a lot of time talking about ways of converting from one representation to another. Hopefully that will help you. Alternatively, you can "pin" Images to a version that did not break your code. And finally: beyond making an announcement on the mailing list, providing an extensive README, providing function deprecation warnings, massively expanding the test suite, and trying to ensure that the API at least remains compatible, I'm frankly not sure there's more I could have done here. As John says, both julia & Images are still young; if we can't break things occasionally, we're going to be stuck with a lot of cruft. --Tim On Friday, October 03, 2014 07:39:04 AM Jan Kybic wrote: > On Friday, September 5, 2014 11:07:05 PM UTC+2, Tim Holy wrote: > > I'm pleased to announce a major overhaul of the Images package. The big > > change > > is deeper integration with other packages: Color and FixedPointNumbers. > > Thank you very much for your work, I am sure these changes are in the good > direction. But of course, some of the changes break existing code, as I > have discovered myself today - after Pkg.update() my code no longer works. > I am sure I will find the problems and correct them but at the moment I > just wanted to make some more general comments: > > a) The seemingly innocent command 'Pkg.update()' is actually quite > dangerous. Could it not warn - "there are important changes in package XXX, > you can read about them in YYY, are you sure you want to update now?" > > b) Backward compatibility is very important. People will get angry if they > have to change their code with every new version. I know it is not always > possible but it would be nice to have the "old style" and "new style" live > together in parallel for some time, while issuing depreciation warnings, > before actually changing the default behaviour. > > Keep up the good work. Yours, > > Jan
