On 22 October 2013 22:10, sebb <seb...@gmail.com> wrote: > On 22 October 2013 21:34, Gary Gregory <garydgreg...@gmail.com> wrote: >> This might be too wacky but I thought I'd offer it up anyway. >> >> It looks like we are going to go with a 1.0 release from trunk RSN. >> We known 2.0 will break BC and will come in a o.a.c.imaging2 package. >> So, why not release 1.0 in a package o.a.c.imaging1? > > This will break compatibility with 0.9.7. > I thought the idea was to release a compatible version?
Ignore that, I see that the package name has changed anyway. >> Gary >> >> >> On Tue, Oct 22, 2013 at 3:40 PM, Damjan Jovanovic <dam...@apache.org> wrote: >> >>> Wow, that's a really good idea! >>> >>> Yes it's feasible. If you'd like to write and commit a patch for it, feel >>> free. >>> >>> Damjan >>> >>> On Tue, Oct 22, 2013 at 9:23 PM, Matt Benson <gudnabr...@gmail.com> wrote: >>> > If the API will be extensible, that's perhaps a different matter, >>> although >>> > in that case maybe the extensible part should be an interface implemented >>> > by ImageFormat's constants. In this case we could convert ImageFormat to >>> an >>> > enum now and still make the API extensible later on. >>> > >>> > Does this sound feasible? >>> > >>> > Matt >>> > >>> > >>> > On Tue, Oct 22, 2013 at 2:12 PM, Damjan Jovanovic <dam...@apache.org> >>> wrote: >>> > >>> >> I would like to avoid an enum there for later versions because I'd >>> >> like to make the API extensible with user-defined image formats, but >>> >> we can add it for 1.0.0. >>> >> >>> >> Damjan >>> >> >>> >> On Tue, Oct 22, 2013 at 9:00 PM, Matt Benson <gudnabr...@gmail.com> >>> wrote: >>> >> > At some point I had had it in mind that ImageFormat should be >>> converted >>> >> to >>> >> > a proper enum type. Can anyone offer any reasons this should not be >>> >> done, >>> >> > particularly before 1.0.0? >>> >> > >>> >> > Matt >>> >> > >>> >> > >>> >> > On Tue, Oct 22, 2013 at 1:44 PM, Damjan Jovanovic < >>> damjan....@gmail.com >>> >> >wrote: >>> >> > >>> >> >> Yes I agree, we might as well release trunk as 1.0.0. I am fixing the >>> >> >> last few bugs in Jira, and then let's get started with the release >>> >> >> :-). Support would be appreciated. >>> >> >> >>> >> >> Damjan >>> >> >> >>> >> >> On Tue, Oct 22, 2013 at 8:19 PM, Raul Kripalani <r...@evosent.com> >>> >> wrote: >>> >> >> > Hello, >>> >> >> > >>> >> >> > @Gregory – many thanks for your input. You surely belong very valid >>> >> >> points >>> >> >> > to the discussion. >>> >> >> > >>> >> >> > The issue I see is that Apache Sanselan 0.97 has such a wide >>> adoption >>> >> in >>> >> >> > the community that even in spite of the last public release being >>> an >>> >> >> > Incubator one, it has earned itself the status of a de-facto >>> library >>> >> for >>> >> >> > image processing out there. It's quite mature and stable for the >>> >> standard >>> >> >> > use cases. IMHO, release 0.97 has the status and bearing of a >>> release >>> >> >> 1.0.0 >>> >> >> > already. >>> >> >> > >>> >> >> > Want it or not, this means that you'll find yourself supporting the >>> >> >> current >>> >> >> > API baseline for quite some time ;-) Bear in mind that the Sanselan >>> >> use >>> >> >> > cases are typically quite static: once you've built your image >>> >> processing >>> >> >> > functionality into your app, it'll probably remain untouched for a >>> >> long >>> >> >> > time. So the user has some functional changes to make in your app, >>> >> they >>> >> >> > won't consider upgrading, let alone investing the effort to adapt >>> >> their >>> >> >> > code to an entirely new API just for the sake of it. >>> >> >> > >>> >> >> > So, in a nutshell, it seems adequate to publish the current trunk >>> as >>> >> >> > version 1.0.0, as folks are indeed already treating it as such out >>> >> there. >>> >> >> > >>> >> >> > @Damjan – what's your take? I can support you these days if you >>> >> decide to >>> >> >> > push out 1.0.0 now! >>> >> >> > >>> >> >> > Regards, >>> >> >> > >>> >> >> > *Raúl Kripalani* >>> >> >> > Apache Camel PMC Member & Committer | Enterprise Architect, Open >>> >> Source >>> >> >> > Integration specialist >>> >> >> > http://about.me/raulkripalani | >>> >> http://www.linkedin.com/in/raulkripalani >>> >> >> > http://blog.raulkr.net | twitter: @raulvk >>> >> >> > >>> >> >> > On Mon, Oct 21, 2013 at 5:23 PM, Gary Gregory < >>> garydgreg...@gmail.com >>> >> >> >wrote: >>> >> >> > >>> >> >> >> On Mon, Oct 21, 2013 at 10:30 AM, Gary Gregory < >>> >> garydgreg...@gmail.com >>> >> >> >> >wrote: >>> >> >> >> >>> >> >> >> > On Mon, Oct 21, 2013 at 9:47 AM, Damjan Jovanovic < >>> >> dam...@apache.org >>> >> >> >> >wrote: >>> >> >> >> > >>> >> >> >> >> Well as the only committer that's really working on the >>> >> internals, I >>> >> >> >> >> am wondering what to do myself now. >>> >> >> >> >> >>> >> >> >> >> I've been working on (and have almost finished) a very large >>> >> change >>> >> >> >> >> affecting virtually everything. When I commit it, the API will >>> >> come >>> >> >> >> >> apart at the seams :-/, and people will not be very happy with >>> the >>> >> >> >> >> rewrites of their own code they'll be doing. >>> >> >> >> >> >>> >> >> >> >> Which of the following would be best: >>> >> >> >> >> 1. Releasing what is in SVN trunk now (maybe minus another API >>> >> >> >> >> breaking change from a few months ago) as 1.0, then adding my >>> >> large >>> >> >> >> >> API-breaking change which will eventually be released as >>> version >>> >> 2.0. >>> >> >> >> >> >>> >> >> >> > >>> >> >> >> > Remember that you'll have to change the package name and Maven >>> >> >> >> coordinates >>> >> >> >> > for 2.0. >>> >> >> >> > >>> >> >> >> >>> >> >> >> The good news is that version 0.97 is in the old package name >>> >> >> >> org.apache.sanselan. This means no jar hell for 1.0 >>> >> >> >> (org.apache.commons.imaging) vs. 0.97. 1.0 which will co-exist >>> with >>> >> >> 0.97 in >>> >> >> >> the same class loader. With option (1), upgrading from 0.97 to 1.0 >>> >> will >>> >> >> >> mean AT LEAST updating all package imports, not that bad. Make >>> sure >>> >> you >>> >> >> >> write good release notes ;) >>> >> >> >> >>> >> >> >> Let me also offer a bit of perspective for your consideration. >>> >> >> Releasing an >>> >> >> >> option (1) 1.0 means supporting it to some extent on the ML and >>> with >>> >> >> >> possible maintenance releases. Since 2.0 is incompatible, do you >>> >> really >>> >> >> >> want to take on maintaining two large code bases (or three if you >>> >> count >>> >> >> >> 0.97)? Right now, there seems to be only one committer with deep >>> >> domain >>> >> >> >> knowledge, you ;) Another possibility -- your (3) -- would be to >>> >> "flush >>> >> >> >> out" another (last?) 0.x "release" to get trunk out there for 0.x >>> >> users, >>> >> >> >> then release 1.0 which would be the new API. It seems >>> self-defeating >>> >> to >>> >> >> >> release a 1.0 knowing the API is not going to live going forward >>> to >>> >> 2.0. >>> >> >> >> With option (2), you are saying, [imaging] has learned its >>> lessons in >>> >> >> >> alpha, it has now grown up to a 1.0-level releasable API. What I >>> do >>> >> not >>> >> >> >> know is how close you are to the new API being done. >>> >> >> >> >>> >> >> >> In the end, you know the audience best and users that adopt a 0.x >>> >> >> product >>> >> >> >> should know that they are taking on a certain level of risk. In >>> >> >> addition, >>> >> >> >> no one is forcing them to update to 1.0. Since you are doing the >>> >> work, >>> >> >> I'll >>> >> >> >> support your efforts with option (1). If you called for a [POLL] >>> >> email >>> >> >> on >>> >> >> >> the user's ML, my guess is that users would be happy with a >>> >> non-breaking >>> >> >> >> 1.0 release. >>> >> >> >> >>> >> >> >> I know that our release process is painful, you might have seen >>> >> >> discussions >>> >> >> >> about it recently, but keep on going, it seems we are close. >>> >> >> >> >>> >> >> >> Gary >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> > Gary >>> >> >> >> > >>> >> >> >> > >>> >> >> >> >> 2. Adding my large change now and API-breaking everything in >>> >> trunk, >>> >> >> >> >> then releasing that as 1.0. >>> >> >> >> >> 3. Releasing what is in SVN trunk now (maybe minus another API >>> >> >> >> >> breaking change from a few months ago) as 0.98, then >>> API-breaking >>> >> >> >> >> everything, and then either releasing a 0.99 or 1.0. (This is >>> >> >> probably >>> >> >> >> >> the hardest option, and may not be possible, since version >>> >> numbering >>> >> >> >> >> of nightly builds will go backwards and JIRA bugs will need to >>> be >>> >> >> >> >> changed.) >>> >> >> >> >> >>> >> >> >> >> Thoughts? Preferences? >>> >> >> >> >> >>> >> >> >> >> Regards >>> >> >> >> >> Damjan >>> >> >> >> >> >>> >> >> >> >> On Mon, Oct 21, 2013 at 3:30 PM, Raul Kripalani < >>> r...@evosent.com >>> >> > >>> >> >> >> wrote: >>> >> >> >> >> > Hello all, >>> >> >> >> >> > >>> >> >> >> >> > Are there any plans for releasing 1.0.0 soon? >>> >> >> >> >> > >>> >> >> >> >> > The last commit was 2 months old and the community will >>> >> hands-down >>> >> >> >> >> benefit >>> >> >> >> >> > from a GA release that includes the bugfixes and code renames >>> >> from >>> >> >> >> >> Sanselan >>> >> >> >> >> > to Commons Imaging, carried out ever since 0.9.7. >>> >> >> >> >> > >>> >> >> >> >> > Can I help in any way? We need the 1.0.0 release for our >>> >> project to >>> >> >> >> >> acquire >>> >> >> >> >> > the fix for IMAGING-49 [1], and we cannot rely on SNAPSHOTs. >>> >> >> >> >> > >>> >> >> >> >> > [1] https://issues.apache.org/jira/browse/IMAGING-49 >>> >> >> >> >> > >>> >> >> >> >> > Thanks, >>> >> >> >> >> > >>> >> >> >> >> > *Raúl Kripalani* >>> >> >> >> >> > Apache Camel PMC Member & Committer | Enterprise Architect, >>> Open >>> >> >> >> Source >>> >> >> >> >> > Integration specialist >>> >> >> >> >> > http://about.me/raulkripalani | >>> >> >> >> >> http://www.linkedin.com/in/raulkripalani >>> >> >> >> >> > http://blog.raulkr.net | twitter: @raulvk >>> >> >> >> >> >>> >> >> >> >> >>> >> --------------------------------------------------------------------- >>> >> >> >> >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>> >> >> >> >> For additional commands, e-mail: user-h...@commons.apache.org >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > -- >>> >> >> >> > E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> >> >> >> > Java Persistence with Hibernate, Second Edition< >>> >> >> >> http://www.manning.com/bauer3/> >>> >> >> >> > JUnit in Action, Second Edition < >>> http://www.manning.com/tahchiev/> >>> >> >> >> > Spring Batch in Action <http://www.manning.com/templier/> >>> >> >> >> > Blog: http://garygregory.wordpress.com >>> >> >> >> > Home: http://garygregory.com/ >>> >> >> >> > Tweet! http://twitter.com/GaryGregory >>> >> >> >> > >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> -- >>> >> >> >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>> >> >> >> Java Persistence with Hibernate, Second Edition< >>> >> >> >> http://www.manning.com/bauer3/> >>> >> >> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/ >>> > >>> >> >> >> Spring Batch in Action <http://www.manning.com/templier/> >>> >> >> >> Blog: http://garygregory.wordpress.com >>> >> >> >> Home: http://garygregory.com/ >>> >> >> >> Tweet! http://twitter.com/GaryGregory >>> >> >> >> >>> >> >> >>> >> >> --------------------------------------------------------------------- >>> >> >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>> >> >> For additional commands, e-mail: user-h...@commons.apache.org >>> >> >> >>> >> >> >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>> >> For additional commands, e-mail: user-h...@commons.apache.org >>> >> >>> >> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>> For additional commands, e-mail: user-h...@commons.apache.org >>> >>> >> >> >> -- >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >> Java Persistence with Hibernate, Second >> Edition<http://www.manning.com/bauer3/> >> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> >> Spring Batch in Action <http://www.manning.com/templier/> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org
