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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
