I thought we had been discussing possibly adding some breaking changes for 1.0.0. That said, I would personally be -0 to "imaging1", though I have to skin in the game.
Matt On Tue, Oct 22, 2013 at 4:10 PM, sebb <[email protected]> wrote: > On 22 October 2013 21:34, Gary Gregory <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > >> 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 <[email protected]> > >> 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 < > >> [email protected] > >> >> >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 <[email protected] > > > >> >> 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 < > >> [email protected] > >> >> >> >wrote: > >> >> >> > > >> >> >> >> On Mon, Oct 21, 2013 at 10:30 AM, Gary Gregory < > >> >> [email protected] > >> >> >> >> >wrote: > >> >> >> >> > >> >> >> >> > On Mon, Oct 21, 2013 at 9:47 AM, Damjan Jovanovic < > >> >> [email protected] > >> >> >> >> >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 < > >> [email protected] > >> >> > > >> >> >> >> 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: [email protected] > >> >> >> >> >> For additional commands, e-mail: > [email protected] > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > -- > >> >> >> >> > E-Mail: [email protected] | [email protected] > >> >> >> >> > 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: [email protected] | [email protected] > >> >> >> >> 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: [email protected] > >> >> >> For additional commands, e-mail: [email protected] > >> >> >> > >> >> >> > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: [email protected] > >> >> For additional commands, e-mail: [email protected] > >> >> > >> >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > >> > > > > > > -- > > E-Mail: [email protected] | [email protected] > > 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: [email protected] > For additional commands, e-mail: [email protected] > >
