commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <Joerg.Schai...@Elsag-Solutions.com>
Subject RE: [id] Review before 1.0 (Summary)
Date Mon, 16 Jan 2006 09:02:42 GMT
Hi Phil,

Phil Steitz wrote on Monday, January 16, 2006 1:27 AM:

[snip]

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

Yeah, I am aware of both problems and my suggestion was not *that* serious, although the truth
lies between the lines as you've explained here for the records.
 
> 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.

Since I never did so before, I don't know yet wheat it really *means*. I'll check the wiki.

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

I'll have a look.

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

I am glad, if we release with uuid, even if it takes more time. Thanks for commitment (*).

- Jörg

(*) "It's like an English breakfirst with bacon and eggs. The hen is just involved, but the
pig is committed."
Cited from an Irish buddy motivating is project team ... :)

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