On Fri, Jan 21, 2011 at 13:45, Massimo Lusetti <[email protected]> wrote: > On Fri, Jan 21, 2011 at 11:13 AM, Andreas Andreou <[email protected]> wrote: > >> On another note, i'm not sure why tapestry-upload needs a separate subproject >> (one can manually exclude commons-fileupload) > > That's a good question... >
In fact, having separate releases would be the only good justification for this. I took a look at the commit history [1] and from 5.1.0.0 till 5.3.0-SNAPSHOT, tapestry-upload's only "real" changes where [2] and [3], the former just before 5.2.0 and the latter just before 5.2.1 [1] https://github.com/apache/tapestry5/commits/trunk/tapestry-upload [2] end of https://github.com/apache/tapestry5/commit/7a521c1185fef67bf24a69ec248164f33d4ae136 [3] https://github.com/apache/tapestry5/commit/614c10ae1809beb13d91123f5573da60db017560 On the minus side, separate releases can result in user frustration & make offering help in the lists more difficult... We could tackle that and shield the user by having Tapestry do some version checking on bootstrap (though it's not obvious how older modules can signal that they're compatible with newer tapestry versions, i.e. it could very well be the case that tapestry-upload 5.2 works as is in tapestry 5.3 but its metadata will not contain that information )... anyway, i dont have a solution yet, but if we don't offer such a runtime service to the users, separate releases can quickly become a hell. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
