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 > >
