On 15 November 2010 01:23, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > On Nov 14, 2010, at 3:43 AM, sebb wrote: > >> On 14 November 2010 11:17, sebb <seb...@gmail.com> wrote: >>> The change of VFS package name has broken lots of Gump builds - which >>> is to be expected. >>> >>> Looking at how this has been solved for other projects, one way to >>> solve this is to create a branch for the VFS 1.x code and use that for >>> the current VFS. >>> Then we create a build for VFS 2. >>> >>> Gump does warn us that there are a lot of projects that depend on VFS >>> directly or indirectly. >>> >>> All of these will have to be modified if they wish to use the next version. >>> >>> Maybe we need to revisit the API breakage? >>> >> >> I've created a tag from just before the package rename, and hopefully >> succeeded in changing Gump to use that version of VFS. >> >> This should give us a better idea of whether the API changes actually >> affect any code that depends on VFS. >> >> It may turn out that the API changes are in areas of code which are >> not actually used externally, or maybe they are easy to fix. >> > > I'm not really sure how that helps. My understanding of Gump is that the > intention is to have projects find these sorts of breakage. What your change > accomplishes is to allow other projects to merrily roll along without > realizing they have a looming problem.
Initially it is a temporary fix to see how whether API changes break the other builds or not. However, when there is a package change, Gump has to provide access to the previous version, until such time as projects update to the new one. For example as has been done with Jexl and Lang and Pool. > I'd really like to not endlessly go on and on with doing this and that with > VFS and never getting a release out. As requested I renamed the packages and > changed the artifactId. Is it done yet? I'm sorry it seems to be taking so long. However, a package name change is not something to be undertaken lightly, as it affects all downstream users. IMO it's important to ensure that the package change really is necessary. > Ralph > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
