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