commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: [VFS] next release
Date Wed, 07 Dec 2011 18:01:33 GMT
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 <sebbaz@gmail.com> wrote:

> On 5 December 2011 22:45, Jörg Schaible <joerg.schaible@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message