On 8 December 2011 13:35, Jörg Schaible <joerg.schai...@scalaris.com> wrote: > sebb wrote: > >> On 8 December 2011 11:01, Jörg Schaible <joerg.schai...@scalaris.com> >> wrote: >>> sebb wrote: >>> >>>> On 8 December 2011 07:11, Jörg Schaible <joerg.schai...@scalaris.com> >>>> wrote: >>>>> Hi, >>>>> >>>>> Gary Gregory wrote: >>>>> >>>>>> I am thinking of a different package name, not just version for VFS on >>>>>> Java 7 because we might want to release more VFS2-based versions that >>>>>> do break binary compatibility. >>>>>> >>>>>> We can retain the VFS name and brand for the project, but I'd prefer >>>>>> o.a.c.vfs<n> to be for VFS2 based work and to create o.a.c.filesystem >>>>>> (or fs) for Java 7 FileSystem-based work. >>>>>> >>>>>> Thoughts? >>>>> >>>>> Until now we had the policy to add the major number to the package name >>>>> i.e. this is org.apache.commons.vfs3 here. >>>> >>>> As I already mentioned earlier in this thread, that may clash with >>>> updates to VFS 2.x that need a new package name. >>> >>> And how long do you expect that both branches are actively developed? It >>> took years from 1.x to 2.x. And why should someone start active >>> development with vfs2 if there's already vfs3 around? >> >> Because AIUI VFS3 targets Java 1.7 up; it won't work on Java 1.5 or 1.6. >> >> I hope no-one is suggesting that VFS no longer be developed for Java >> 1.6 just yet. > > I did not say that, but I don't expect major refactorings and an API > redesign for VFS2 if there's already a successor (and this time with an API > defined by the JDK). We should be interested ourselves to stay API- > compatible in the VFS2 series.
Of course, but it may not be possible to maintain binary compatibility. Are we sure that new API is perfect? Or at least fixable without breaking compat? I suppose we could use vfs2a, vfs2b etc. However, given that VFS3 is going to be a different API altogether, I think it would be better to use a package name that is more distinctive. > - Jörg > > > --------------------------------------------------------------------- > 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
