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? Gary On Wed, Dec 7, 2011 at 11:49 AM, sebb <seb...@gmail.com> wrote: > On 5 December 2011 22:45, Jörg Schaible <joerg.schai...@gmx.de> wrote: > > Hi Gary, > > > > Gary Gregory wrote: > > > >> Hi All: > >> > >> I've made several improvements to VFS over the last couple of months > which > >> feels ready for a release soon. > >> > >> One important internal change is that the builds runs almost all unit > >> tests > >> :) > > > > I saw your efforts and this is really a great improvement! Thanks! > > > >> I've not found an easy way to embed a WebDAV server in the tests like > >> JackRabbit, which would be nice to do. > > > > Definitely :) > > > >> I know Ralph just mentioned thoughts of a VFS3 on top of Java 7, which > is > >> great news indeed. This feels like it needs a new name instead of a > >> version change though because the change is so radical (and nice.) > >> > >> Thoughts? > > > > I'd keep the name, it's a brand here and if we name it VFS3 and document > > that it is based on Java 7 technology, so why change it? > > The current release targets Java 1.5 and uses the package name vfs2; > the name was changed from o.a.c.vfs because 2.x is not binary > compatible with 1.x. > > If there is to be any development of VFS 2.x on Java 1.5 or Java 1.6 > that requires breaking binary compatibility again (which is not > impossible), this could cause a clash with the package name for the > new component VFS3. > > Ideally there should be a different package name prefix for each the > two components; failing that, at least they must use different numeric > suffix ranges. > Otherwise users may not be able to upgrade to Java 7 cleanly. > > Maven ids also need to be distinct, but that is less of an issue (for > once). > > > - 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 > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
