On Mon, 8 Sep 2003, Adam R. B. Jack <[EMAIL PROTECTED]> wrote: > However, most of my statement (and now question) is about > friend-of-gump behaviour, and having that project is good, but not > "friendly" 'cos it forces work onto sub-projects.
I'm not sure. > Do you not agree that the project should manage itself, should > create the new (temporarily unstable) codebase as the sub-named > project, and should either alias (via <project > name="commons-httpclient" .. <depend > name="commons-httpclient-old-stable-branch" inherit="all") or rename > projects in order to manage it for folk? It would be nice if they did. Many projects consider Gump either a community service maintained by others (most committers don't even know they have commit access to the jakarta-gump module) or a nuisance. I think it is perfectly legitimate for a project to move forward and break backwards compatibility after a deprecation period that's been long enough and included at least one stable release. Whether such a project decides to move forward in CVS HEAD or in a branch is up to its committers. If they manage its Gump descriptor to take the problem into account is a different issue - see above. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
