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 >
