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
