Am 01.09.2010 12:50, schrieb Chad La Joie:
Maybe I just haven't encountered them but I've never seen a case where projects would have benefited from this type of fine grained packaging.
I put the ideas together because we would benefit from them. Our project just need the logging essentials but not the XML/Groovy configuration stuff or any of the other appenders. However, there were releases in the past that just contained modifications in those area and we were confronted with requests to updated an "outdated" version for Logback which actually wasn't outdated. I can also see some benefits on embedded devices which look for ever kB they could save.
As far as the versioning goes, I would recommend against independent versions unless you are going to establish a consistent and rigid versioning policy dealing with API changes and backwards/forwards compatibility. To date logback has not had that and if it doesn't in the future you'll end up having to describe exactly which versions of which packages work with exactly which versions of other packages. That would be very cumbersome and messy I think.
I don't really see this as an issue. There are well established best practices for versioning as well as defining requirements, etc. Maybe I'm wrong but to me it seems that Ceki already started adopting them for SLF4J and also for Logback (that's why it's still pre-1.0 to allow evolution of the API). Another benefit is that Logback Essentials could be declared 1.0 independent from other packages. IMHO this would also be a positive signal to the community. And, as I said before, although the packages may have individual versions they could still be released as one convenience drop. -Gunnar -- Gunnar Wagenknecht gunnar@wagenknecht.org http://wagenknecht.org/