The packaging rename is a must (whether to o.a.c.imaging or o.a.c.imaging1), as the project has transitioned from Incubator to Apache Commons, and in the process it has been rebranded from Apache Sanselan to Apache Commons Imaging.
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 Tue, Oct 22, 2013 at 11:10 PM, 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? > > > 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 > >
