StefanOltmann commented on PR #359:
URL: https://github.com/apache/commons-imaging/pull/359#issuecomment-2054089370

   Feel free to approach this matter in any way you see fit, but I'd like to 
offer my perspective:
   
   It's generally ill-advised to utilize a snapshot version of a dependency in 
a production application, as its behavior can change unpredictably and may not 
undergo thorough testing.
   
   Currently, this project boasts over 400 stars, suggesting that potentially 
400+ individuals or projects are employing it in production environments—thus 
risking the corruption of user metadata. Despite being labeled as "alpha," 
there's no stable alternative version available, at least not one that's been 
updated recently.
   
   While Android offers "ExifInterface" for handling metadata, JVM desktop 
applications lack adequate alternatives, especially for writing metadata. While 
"metadata-extractor" suffices for reading, options for writing are limited, 
with "pixymeta" being the only one I found. I chose to build upon Commons 
Imaging for "Ashampoo Kim" due to issues encountered with "pixymeta", notably 
its tendency to corrupt Makernote data during writing due to a design flaw. 
Commons Imaging only had this one serious issue, which Gary Lucas addressed in 
said JIRA comment.
   
   In my view, it's crucial to recognize the likelihood of numerous production 
projects relying on this library, underscoring the responsibility that 
accompanies its maintenance. "Alpha" status or not, people trust Apache 
projects and you shouldn't let them down.
   
   Should any bugs be discovered in "Ashampoo Kim" I would promptly release a 
fix — not only due to the dependency of my own production project "Ashampoo 
Photos", but also out of a broader sense of responsibility to the community.
   
   Even with the existence of my library, people might still want to use 
Commons Imaging, because my library comes with a Kotlin dependency. That's 
something a pure JVM project might not want.
   
   So in my view Commons Imaging is for pure JVM projects that need to write 
metadata and can't accept a Kotlin dependency, still the go-to project for 
production use. Keep that in mind.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org

Reply via email to