From 2d02e02b8cfd3b45294c85efa310952effed809a Mon Sep 17 00:00:00 2001 From: Bryan Veloso Date: Fri, 23 Mar 2012 16:42:14 -0700 Subject: [PATCH] Intial pass of the 2.0 release notes. --- docs/changelog.rst | 66 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) diff --git a/docs/changelog.rst b/docs/changelog.rst index 742ad29..f27de82 100644 --- a/docs/changelog.rst +++ b/docs/changelog.rst @@ -1,6 +1,68 @@ Changelog ========= +v2.0.0 +------ + +- Added the concept of cache state backends. Cache state backends assume + control of an image's CRUD actions from `ImageSpec` in versions past. The + default backend maintins the current behavior: invalidating an image and + deleting it, then validating that it creates the file if it doesn't already + exist. One can create custom cache state backends to control how their + images are cached (e.g., Celery, etc.). + + ImageKit ships with three built-in backends: + + - ``imagecache.base.PessimisticImageCacheBackend`` - A very safe image cache + backend. Guarantees that files will always be available, but at the cost + of hitting the storage backend. + - ``imagecache.base.NonValidatingImageCacheBackend`` - A backend that is + super optimistic about the existence of spec files. It will hit your file + storage much less frequently than the pessimistic backend, but it is + technically possible for a cache file to be missing after validation. + - ``imagecache.celery.CeleryImageCacheBackend`` - A pessimistic cache state + backend that uses celery to generate its spec images. Like + ``PessimisticCacheStateBackend``, this one checks to see if the file + exists on validation, so the storage is hit fairly frequently, but an + image is guaranteed to exist. However, while validation guarantees the + existence of *an* image, it does not necessarily guarantee that you will + get the correct image, as the spec may be pending regeneration. In other + words, while there are `generate` tasks in the queue, it is possible to + get a stale spec image. The tradeoff is that calling `invalidate()` + won't block to interact with file storage. + +- ``resize.Crop`` has been renamed to ``reszie.Fill``. Using ``resize.Crop`` + will throw a ``DeprecationWarning``. + +- New processors have been added: + + - ``crop.BasicCrop`` - Crop using provided box. + - ``crop.SmartCrop`` - Crop to provided size, trimming based on entropy. + - ``crop.TrimBorderColor`` - Trim the specified color from the specified + sides. + - ``resize.AddBorder`` - Add a border of specific color and size to an + image. + - ``resize.Resize`` - Scale to the provided dimensions (can distort). + - ``resize.ResizeToCover`` - Scale to the smallest size that will cover + the specified dimensions. Used internally by ``Fill`` and ``SmartFill``. + - ``resize.ResizeToFill`` - Scale to fill the provided dimensions, + trimming away excess using ``Crop``. + - ``resize.ResizeToFit`` - Scale to fit the provided dimensions. + - ``resize.ResizeCanvas`` - Takes an image an resizes the canvas, using a + specific background color if the new size is larger than the current + image. + - ``resize.SmartFill`` - Scale to fill the provided dimensions, trimming + away excess using ``SmartCrop``. + +- ``mat_color`` has been added as an arguemnt to the ``ResizeProcessor``. If + set, the target image size will be enforced and the specified color will be + used as background color to pad the image. + +- We now use `Tox`_ to automate testing. + +.. _`Tox`: http://pypi.python.org/pypi/tox + + v1.1.0 ------ @@ -15,6 +77,7 @@ v1.1.0 - The private ``_Resize`` class has been removed. + v1.0.3 ------ @@ -30,6 +93,7 @@ v1.0.3 - Fixed PIL zeroing out files when write mode is enabled. + v1.0.2 ------ @@ -42,6 +106,7 @@ v1.0.2 - Fixed a regression from the 0.4.x series in which ImageKit was unable to convert a PNG file in ``P`` or "palette" mode to JPEG. + v1.0.1 ------ @@ -51,6 +116,7 @@ v1.0.1 - Fixed the included admin template not being found when ImageKit was and the packaging of the included admin templates. + v1.0 ----