You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Benedikt Ritter <br...@apache.org> on 2017/05/17 21:22:08 UTC
[IMAGING] Why don't we just release it?
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Rob Tompkins <ch...@gmail.com>.
> On May 17, 2017, at 5:22 PM, Benedikt Ritter <br...@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?
I’ve done some reading through the code a bit, and the only drawback is the lack of javadocs in the code. That doesn’t seem insurmountable.
-Rob
>
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Benedikt Ritter <br...@apache.org>.
> Am 17.05.2017 um 19:46 schrieb Gary Gregory <ga...@gmail.com>:
>
> If you dig through the mailing list, you will find a few proposal for a
> road map out of "0.97" land. IIRC, the code was deemed in flux and BC
> breaking changes planned.
>
> For me, It's fine to cut 1.0 and to NOT be shy about releasing a 2.0 with
> BC breaks.
We have a lot of check style errors about magic numbers and wrong code style (I fixed some of those). I’m not sure we really need to fix them now, given the fact that they have been there forever. My hope is, that a 1.0 will attract new people.
Benedikt
>
> Gary
>
> On Wed, May 17, 2017 at 2:22 PM, Benedikt Ritter <br...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
> JUnit in Action, Second Edition
> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
> Spring Batch in Action
> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
Gary Gregory wrote:
> If you dig through the mailing list, you will find a few proposal for a
> road map out of "0.97" land. IIRC, the code was deemed in flux and BC
> breaking changes planned.
>
> For me, It's fine to cut 1.0 and to NOT be shy about releasing a 2.0 with
> BC breaks.
+1
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Gary Gregory <ga...@gmail.com>.
If you dig through the mailing list, you will find a few proposal for a
road map out of "0.97" land. IIRC, the code was deemed in flux and BC
breaking changes planned.
For me, It's fine to cut 1.0 and to NOT be shy about releasing a 2.0 with
BC breaks.
Gary
On Wed, May 17, 2017 at 2:22 PM, Benedikt Ritter <br...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [IMAGING] Why don't we just release it?
Posted by Amey Jadiye <am...@gmail.com>.
+1 , went through the code seems we can have all the feature in future
releases and ATM seems stable API's so can release 1.0
Also, as this will be the very first release we should keep code and build
clean which sets protocol for future releases.
so atleast test apache-rat:check clirr:check checkstyle:check
findbugs:check javadoc:javadoc these must be passed before release.
-Amey
On May 18, 2017 11:52 PM, "Benedikt Ritter" <br...@apache.org> wrote:
> Am 18.05.2017 um 12:54 schrieb sebb <se...@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.
>
> This should also be highlighted in the release notes.
Definitely.
Benedikt
>
>
> On 18 May 2017 at 17:09, Rob Tompkins <ch...@gmail.com> wrote:
>>
>>> On May 18, 2017, at 9:20 AM, Benedikt Ritter <br...@apache.org> wrote:
>>>
>>> Hi Damjan,
>>>
>>>> Am 18.05.2017 um 08:16 schrieb Damjan Jovanovic <da...@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=✓
<https://github.com/search?l=Maven+POM&q=commons-imaging&type=Code&utf8=%E2%9C%93>
>>
>> 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 <br...@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:
dev-unsubscribe@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
dev-help@commons.apache.org>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Pascal Schumacher <pa...@gmx.net>.
Am 19.05.2017 um 08:17 schrieb Jörg Schaible:
> We failed to release for years and the current SNAPSHOT is the de facto API
> now. So qwe better make this official releasing 1.0 and move on immediately
> with 2.0 to adjust any stuff that has to be corrected.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Jörg Schaible <jo...@bpm-inspire.com>.
Hi,
sebb wrote:
> On 18 May 2017 at 19:22, Benedikt Ritter <br...@apache.org> wrote:
>>
>>> Am 18.05.2017 um 12:54 schrieb sebb <se...@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.
We failed to release for years and the current SNAPSHOT is the de facto API
now. So qwe better make this official releasing 1.0 and move on immediately
with 2.0 to adjust any stuff that has to be corrected.
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by sebb <se...@gmail.com>.
On 18 May 2017 at 19:22, Benedikt Ritter <br...@apache.org> wrote:
>
>> Am 18.05.2017 um 12:54 schrieb sebb <se...@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 <ch...@gmail.com> wrote:
>>>
>>>> On May 18, 2017, at 9:20 AM, Benedikt Ritter <br...@apache.org> wrote:
>>>>
>>>> Hi Damjan,
>>>>
>>>>> Am 18.05.2017 um 08:16 schrieb Damjan Jovanovic <da...@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 <br...@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-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>>
>>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
>>>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Benedikt Ritter <br...@apache.org>.
> Am 18.05.2017 um 12:54 schrieb sebb <se...@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.
>
> This should also be highlighted in the release notes.
Definitely.
Benedikt
>
>
> On 18 May 2017 at 17:09, Rob Tompkins <ch...@gmail.com> wrote:
>>
>>> On May 18, 2017, at 9:20 AM, Benedikt Ritter <br...@apache.org> wrote:
>>>
>>> Hi Damjan,
>>>
>>>> Am 18.05.2017 um 08:16 schrieb Damjan Jovanovic <da...@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 <br...@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by sebb <se...@gmail.com>.
On 23 May 2017 at 09:59, Emmanuel Bourg <eb...@apache.org> wrote:
> Le 18/05/2017 à 18:54, sebb a écrit :
>> I think the release should be marked as ALPHA.
>> This is because:
>> - there are many unresolved issues
>> - it's highly likely that the next release will break compatibility
>
> +1 for an alpha release, ideally with its dedicated namespace to avoid
> conflicts with future releases (i.e. package changed to
> org.apache.commons.imaging.alpha1 and artifactId set to
> commons-imaging-alpha1).
+1, good idea
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Emmanuel Bourg <eb...@apache.org>.
Le 18/05/2017 à 18:54, sebb a écrit :
> I think the release should be marked as ALPHA.
> This is because:
> - there are many unresolved issues
> - it's highly likely that the next release will break compatibility
+1 for an alpha release, ideally with its dedicated namespace to avoid
conflicts with future releases (i.e. package changed to
org.apache.commons.imaging.alpha1 and artifactId set to
commons-imaging-alpha1).
Emmanuel Bourg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Gary Gregory <ga...@gmail.com>.
On Thu, May 18, 2017 at 9:54 AM, sebb <se...@gmail.com> wrote:
> I think the release should be marked as ALPHA.
> This is because:
> - there are many unresolved issues
> - it's highly likely that the next release will break compatibility
>
> This should also be highlighted in the release notes.
>
The seems like the safest most reasonable option ATM.
Gary
>
>
> On 18 May 2017 at 17:09, Rob Tompkins <ch...@gmail.com> wrote:
> >
> >> On May 18, 2017, at 9:20 AM, Benedikt Ritter <br...@apache.org>
> wrote:
> >>
> >> Hi Damjan,
> >>
> >>> Am 18.05.2017 um 08:16 schrieb Damjan Jovanovic <da...@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=✓
> <https://github.com/search?l=Maven+POM&q=commons-imaging&type=Code&utf8=%E2%9C%93>
> >
> > 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 <br...@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-unsubscribe@commons.apache.org
> >>>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>>
> >>>>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:
> dev-unsubscribe@commons.apache.org>
> >> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
> dev-help@commons.apache.org>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459>
JUnit in Action, Second Edition
<https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021>
Spring Batch in Action
<https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action>
<http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [IMAGING] Why don't we just release it?
Posted by sebb <se...@gmail.com>.
I think the release should be marked as ALPHA.
This is because:
- there are many unresolved issues
- it's highly likely that the next release will break compatibility
This should also be highlighted in the release notes.
On 18 May 2017 at 17:09, Rob Tompkins <ch...@gmail.com> wrote:
>
>> On May 18, 2017, at 9:20 AM, Benedikt Ritter <br...@apache.org> wrote:
>>
>> Hi Damjan,
>>
>>> Am 18.05.2017 um 08:16 schrieb Damjan Jovanovic <da...@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 <br...@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Rob Tompkins <ch...@gmail.com>.
> On May 18, 2017, at 9:20 AM, Benedikt Ritter <br...@apache.org> wrote:
>
> Hi Damjan,
>
>> Am 18.05.2017 um 08:16 schrieb Damjan Jovanovic <da...@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 <br...@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-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [IMAGING] Why don't we just release it?
Posted by Benedikt Ritter <br...@apache.org>.
Hi Damjan,
> Am 18.05.2017 um 08:16 schrieb Damjan Jovanovic <da...@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…
Benedikt
>
> Damjan
>
>
> On Wed, May 17, 2017 at 11:22 PM, Benedikt Ritter <br...@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Damjan Jovanovic <da...@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
Damjan
On Wed, May 17, 2017 at 11:22 PM, Benedikt Ritter <br...@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [IMAGING] Why don't we just release it?
Posted by Rob Tompkins <ch...@gmail.com>.
> On May 17, 2017, at 5:22 PM, Benedikt Ritter <br...@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?
I'd be willing to lend a hand with trying to release it.
-Rob
>
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IMAGING] Why don't we just release it?
Posted by Pascal Schumacher <pa...@gmx.net>.
I know nothing imaging, but in principle I agree. If the code is useful,
release it. Do not hold back forever.
Am 17.05.2017 um 23:22 schrieb Benedikt Ritter:
> 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org