On 18 May 2017 at 19:22, Benedikt Ritter <brit...@apache.org> wrote: > >> Am 18.05.2017 um 12:54 schrieb sebb <seb...@gmail.com>: >> >> I think the release should be marked as ALPHA. >> This is because: >> - there are many unresolved issues > > Yes, but I don’t think we could push out 1.0 anyway. > >> - it's highly likely that the next release will break compatibility > > Why do you think this is the case? Can you give some examples of APIs we will > likely need to break to move forward? Something that has worked in the past > is removing those parts for the release as we did for commons-text and > commons-lang.
As I recall, there were still a lot of non-private mutable fields. Encapsulating these will break compat. I don't think there is a clear distinction between classes which are intended to be part of the public API and those which are not. This increases the risk that a class that is part of the public API may need to be changed incompatibly. >> >> This should also be highlighted in the release notes. > > Definitely. > > Benedikt > >> >> >> On 18 May 2017 at 17:09, Rob Tompkins <chtom...@gmail.com> wrote: >>> >>>> On May 18, 2017, at 9:20 AM, Benedikt Ritter <brit...@apache.org> wrote: >>>> >>>> Hi Damjan, >>>> >>>>> Am 18.05.2017 um 08:16 schrieb Damjan Jovanovic <dam...@apache.org>: >>>>> >>>>> Imaging is in quite a sad state compared to javax.imageio, with very >>>>> limited JPEG support that is hard to improve without major research, and >>>>> doesn't add that much value. People seem to mostly use it for extracting >>>>> image metadata. >>>>> >>>>> I would like to see most of the following in 1.0: >>>>> * Proper support for multi-image formats, where you can see individual >>>>> properties for each image >>>>> * Thumbnail support for image formats that support it >>>>> * Support for incremental loading of image formats like progressive JPEG >>>>> * Non-blocking I/O >>>>> * Random access file I/O >>>>> * Support for enormous images, too big to fit in memory, by processing >>>>> them >>>>> line-by-line or tile-by-tile >>>>> * Independence from java.awt, and Android support >>>>> * Imaging as a javax.imageio extension that provides the JVM with support >>>>> for new image formats >>>> >>>> Any reason we can’t add this after 1.0? I’d like to get the release train >>>> going for imaging. Once we have a 1.0 I think it will be easier to push >>>> out incremental releases… >>>> >>> >>> To add to Benedikt’s point here there are a considerable number of projects >>> depending on 1.0-SNAPSHOT: >>> >>> https://github.com/search?l=Maven+POM&q=commons-imaging&type=Code&utf8=✓ >>> >>> So, if we feel that the code is in a relative stable place now, why not cut >>> a 1.0 and try to make these improvements as time goes on. >>> >>> I’d be happy to RM for it if necessary. >>> >>> -Rob >>> >>>> Benedikt >>>> >>>>> >>>>> Damjan >>>>> >>>>> >>>>> On Wed, May 17, 2017 at 11:22 PM, Benedikt Ritter <brit...@apache.org> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> Imaging's inception year is 2007. It has left the incubator around 2009. >>>>>> There hasn’t been a release under the Apache Commons umbrella, for >>>>>> various >>>>>> reason. I think we gave the initial contributors a hard time because we >>>>>> focused to much on code instead of community. >>>>>> Imaging is out there. People are using it. I’ve seen project simply >>>>>> depending on a SNAPSHOT version. This code is useful to a large group of >>>>>> people. >>>>>> So I propose that we just release it. >>>>>> >>>>>> WDYT? >>>>>> >>>>>> Benedikt >>>>>> >>>>>> P.S.: Please no „we need to fix this and that“ comments, if you’re not >>>>>> intending to fix this stuff. >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> <mailto:dev-unsubscr...@commons.apache.org> >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> <mailto:dev-h...@commons.apache.org> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
