[EMAIL PROTECTED] wrote:
>
> Regarding peer review and "releasing" - if the component is used in a
> product, it'll be released as part of the product.
Delurking ...
One caution along these lines -- this will require Jakarta project
committers to
behave differently with respect to "library"-sourced code than they do
at
external projects we have dependencies on. As a Tomcat committer, do I
look at
the code inside jakarta-regexp (which 4.0 depends on), or log4j (if/when
logging
support is migrated to that), or Ant? No ... once I have determined
that the
projects meets my needs, I count on the committers of those projects to
do a good
job of release management, and then rely on released versions. But now,
I have
to look at (some of) this code differently, because it is not being
"released" in
the same sense.
In the initial cases, this will not make a huge amount of difference --
the
primary authors of the shared code are likely to be the same folks as
the
committers on the first project that uses it -- but the *second* project
that
comes along and uses that code needs to be aware that they need to treat
it (for
code management purposes) as a potential code contribution, not as a
released
"product". If that's what we want, we should make that clear in the
docs for the
overall library, because it will be a habit change versus what people
are used to
doing.
For me personally, I'm going to treat code I contribute to in the shared
environment more as a "product" than an "available code base", but to
each their
own.
>
> If it is productized and released as stand-alone - normal jakarta rules
> should apply.
+1
>
> In the STATUS file we should list all releases the component is part of,
> and a "component status":
> - experimental
> - not released
> - released as part of project foo.x.y
> - released standalone
Does "experimental" correspond to "code that you're welcome to use, but
you had
better review it for yourself" per the above discussion?
+1 on status marking, although the "released as part of" stuff is going
to be
hard to keep up to date unless the using project's committers do it.
>
> ( and of course, my initial proposal that any project should be able to
> tag the workspace when they have a release, so they can re-create the
> build later and be able to refer to the state of the component when it was
> included in the project release ).
+1.
>
> Costin
Craig
