commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Pugh" <ep...@upstate.com>
Subject RE: [configuration] Loading and Saving
Date Wed, 08 Sep 2004 13:13:00 GMT
I think it boils down to "is anyone doing the work"..  If Emmanuel is hot on
getting this done in the very near future, then lets add it.  Emmanuel, if
you view this as a 2 week project to properly get done, then lets leave it
for 1.0.1.  There is no reason that 1.0.1 can't come out 2 or 3 weeks after
1.0.  Heck, there isn't any reason why 1.1 can't come out 2 or 3 weeks after
1.0!  Which is I think what we should name the next version that doesn't
have vector and throws Exceptions on missing values..

Personally, I want the switch to be able to throws Exceptions or return
nulls, and then dump the nulls in the next version.  I wouldn't worry too
much about backwards compatibilty.  We're at the 1.0 stage, and don't have
that many users..  I think, as long as we document them, that there are
backwards compatiblities, then they are okay.

Eric

> -----Original Message-----
> From: Emmanuel Bourg [mailto:smanux@lfjr.net]
> Sent: Wednesday, September 08, 2004 12:45 PM
> To: Jakarta Commons Developers List
> Subject: Re: [configuration] Loading and Saving
>
>
> Henning P. Schmiedehausen wrote:
>
> > I like all of this. However, even more I'd like to get 1.0 finally out
> > of the door. I'm really willing to tell our users, that they can rely
> > only on the non-deprecated method signatures in the
> > o.a.c.c.Configuration interface and that everything else can and will
> > be changed post-1.0, but for the moment, getting this stuff released
> > is my #1 prio.
>
> Releasing the 1.0 final is also my top priority, while I agree to
> sacrifice features for this (like automatic reloading, support for
> additional types & more configuration formats) I don't want to sacrifice
> quality (API consistency, testing & documentation), that's why I call
> for these changes now. I don't want to be tied to backward compatibility
> concerns once 1.0 is released because we didn't take the time to address
> these inconsistencies.
>
>
> > I also like the proposal to make the various implementations
> > pluggable. A small application that needs only PropertiesConfiguration
> > should not be punished to drag all of the XML libraries
> > around. Splitting c-c into a "base" package with maybe only
> > commons-lang and commons-collections as dependencies and one or more
> > "optional" packages would be a good thing.
>
> I haven't tested but I think it's already the case, you can use
> PropertiesConfiguration without including the XML libraries.
>
>
> > However, we are already at rc1 state. Pulling the rc1 back would mean,
> > that at least I would go ahead an do the Turbine 2.3.1 release on a
> > snapshot which would IMHO a sad thing.
>
> Well, the merit of the rc1 is to provide and temporary official release
> that can sweep away the various unofficial snapshots and bring more
> testing and feedback on the project. But I don't consider it good enough
> in this state to become a final release.
>
>
> > So please. Let's find an agreement on the get<xxx> semantics, do one
> > more RC and the CfV the release.
>
> I don't mind if we revert to a null-when-missing semantic now and add a
> switch later for exception-when-missing.
>
> Emmanuel Bourg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message