About the *internal* and @internal (package & annotation); Of course if we could come up with a "binding" convention on the source layout and package name for all projects, it would be really nice (i.e. the *internal* package convention). (Oh, a common pom where only the source/test/site would be specific and allow automated reports and release vote publication... just dreaming out loud)
But as a pragmatist, I'd rather have the @internal annotation that can serve as an intermediate, easy to use way to determine stability (both for the dev and the user) than nothing that slows down release cycles to a crawl; forcing projects to align on a source layout convention is likely bound to fail or at least a very (very very) long path. One of the goal is to allow at least easier - if not faster - release cycles; as devs, we'd be made easily aware that we are tinkering with the API contract and for release voting, it gets easier to control that we've not unintentionally screwed it up. Oh, and I do agree on the immutability / thread safety doc. :-) Cheers, Henrib -- View this message in context: http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4161225.html Sent from the Commons - Dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
