commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [id] Review before 1.0 (Summary)
Date Mon, 16 Jan 2006 00:26:50 GMT
On 1/15/06, Jörg Schaible <joerg.schaible@gmx.de> wrote:
> Hi Phil,
>
> Phil Steitz wrote:
>
> > <snip/>
> >>
> >> For me the question is, does a normal user really care about the
> >> specifics of an unique id. The most difference is the returned type of
> >> the id, because that may impact other parts of the code (e.g. DB).
> >
> > I think many apps will care about more than just the type as in string
> > or numeric, though I agree that the need for multiple different types
> > in one application will be rare.  Some applications will want the id
> > to be random, even "secure" (e.g. session ids), some will want
> > sequential ids, etc.  So I think the different types are significant.
> > The real questions are  a) do we care to make different
> > implementations within type pluggable and b) do we want to provide
> > static methods that get ids of the different types directly as a
> > convenience.  Answer to a) is probably leave it to the user and b) is
> > it is nice to have, but again gets unweildy with too many generators.
> > So, I guess I am in favor of simplifying down to just providing the
> > implementations - no factory, no utils class.
>
> OK. Fine with me. I'll drop it.

Lets make sure no one else is opposed. Stephen?
>
> >> > One thing that I would like for us to consider is to omit the uuid
> >> > generators from 1.0.  There is a lot to do to get that package into
> >> > releaseable state, including spec compliance review, and I am a little
> >> > concerned with our ability to support it once released, as the
> >> > original developer is no longer working on this code.
> >>
> >> Uuuh! Cough! Bummer! When I look into the answers given to a lot of users
> >> over the last two years, they were always told, c-id is stable and
> >> reliable, we need just to close the minor issues left in Bugzilla and
> >> clean-up the docs.
> >
> > I don't ever recall anyone using the terms "stable" or "reliable" in
> > reference to the UUID code.  The code from [lang] is certainly stable.
> >  I did respond to one inquiry with the statement that "The main thing
> > standing in the
> > way of promotion to commons proper and a release is review and validation
> > of
> > the UUID code. "  The "review and validation" (against the spec) of
> > the UUID code is a lot of work, as you can see.
>
> OK. You're right. Could not find anything else in the archives.
>
> >> I know quite some projects that use a snapshot of c-id
> >> to generate UUIDs in production (including some of mine).
> >
> > I don't know what we can do to make it more clear that people should
> > *not* depend on code in the commons sandbox, or any unreleased
> > snapshots.
>
> Release more often ? ;-)
>

Easier said than done, but I mostly agree with you.  I say "mostly"
because some sandbox projects will never get the community and quality
necessary to get to a release, so releasing them too early would
actually be a bad thing, IMHO. That is why it is dangerous to depend
on them.  There is sort of a chicken and egg problem here - some argue
that unless you release something you can't build community.

Another problem that we have in commons is that we really want to
maintain backward compatibility between major releases, so we have to
worrry a lot about getting the API right before the initial release. 
We can fix bugs, improve implementations and add functionality in .x
releases, but the API we release intially is what we are more or less
stuck with for some time.  This slows us down considerably compared to
projects whose core product is not an API.

In any case, I think we have critical mass to get [id] promoted and
released, and the API decisions left to make are fairly simple,  so we
should agree on a release plan and get the work done.  Your arguments
have convinced me at least that we should push forward to include the
uuid stuff.  If you want to take a stab at a release plan and
volunteer to be release manager, feel free to go for it.  I will help
with mechanics as necessary.  Have a look at the releas plan wiki
pages out there for [scml] or old ones for [math], [digester],
[betwixt] et al as examples.

 <snip/>
> >>
> >> Fact is, that UUIDs are part of c-id now for exactly two years and
> >> despite the fact, that c-id had no proper release, they are already used.
> >> Even I cannot use c-id-1.0, if it is without UUID support ... :-/
> >
> > This is a do-ocracy, so if you are willing to do the work to get all
> > of the UUID code into releasable state and verify compliance against
> > the spec, I am +1 to push forward.  I just thought that we could get
> > promotion and a release out faster if we omitted this package from the
> > 1.0 plan.
>
> Fair enough. Well, in this case I would really wait until uuid is ready.
> Releasing c-id without uuid is IMHO worse than waiting longer for the
> proper release. I am willing to work on it, but I cannot say a lot about
> the compliance and if I really can handle that regarding my work load.
> Nevertheless my simple code review produced enough tasks that have to be
> done also for a final release. I'll just continue ...

I will help with the spec compliance and code review.  Maybe others
can too.  My time is also limited, but this is something I can do. 
Thanks for picking this up.

Phil

---------------------------------------------------------------------
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