Hi Rauel Nice to meet you too :). Thank you for the positive feedback.
Agreed. If there are no further objections, we'll go with option 1. I would appreciate some help with making the release, as my attempts to release 4 prior RCs have failed, the most recent being RC4: http://mail-archives.apache.org/mod_mbox/commons-dev/201209.mbox/%3CCAJm2B-nbnbJwNUKkAtapZuzT5jfFODsk1aXcdsUUeoC%2BxXrDKg%40mail.gmail.com%3E Though I've fixed most of those problems, and will be sending out a reply to Gary Gregory's reply shortly. Yes it still uses SVN. That sounds good. Regards Damjan On Mon, Oct 21, 2013 at 4:01 PM, Raul Kripalani <[email protected]> wrote: > Hi Damjan, > > Nice to meet you! And many thanks for your quick turnaround. > > Apache Sanselan / Commons Imaging is a widely used library in the community > in its 0.9.7 incubator version. As such, I strongly believe that the > current version of the code deserves to be promoted to 1.0.0. It's a stable > library, practically the only OSS library powerful enough for image > manipulation. > > Moreover, it is very confusing for users (including me) to discover that > Sanselan was integrated into Commons Imaging two years ago, yet that no > official release has been made ever since under that branding. > > For all this, I encourage option 1 ASAP. You can cut a release now with > version number 1.0.0, without backing out the breaking change you mention > in your email. As it is, the package renaming itself will break current > consumers anyway! > > Then continue working on 2.0.0 within trunk (the project still uses SVN, > right?), and keep the imaging-1.0.0 branch for minor and patch releases. > > What do you think? > > 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 3:47 PM, 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. >> 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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
