> > > Otherwise I suggest we change the name that's in there to
> > > was released in Callisto.
> > Point taken. The way I was looking at these things is that
> > *new* bundles. Teams can use them as needed. In many
> > original bundlings were "wrong" or inconvenient. For
> > shipped org.eclipse.equinox.servlet.api. That is now javax.servlet
> > and javax.servlet.jsp. We did this to better accomodate
> > usecases and conventions put forward in Orbit. It is not
> > change in that people can still get and use the old bundle with
> > loss of function.
> Yes, for the logging example, though, I'm not sure BOTH bundles (old
> new) could co-exist and still work right (e.g. if some system-wide
> Singleton is supposed
> to exist). And, we _might_ be able to get previous users to switch,
> rather be prepared with a binary compatible story ... I think one
> strategy would be to also provide a new
> bundle with old name, and it simply import and re-export packages
> newly named bundle?
There will certainly be issues like this that surface
with or without Orbit and regardless of what names we choose (e.g., we
are not the only ones producing bundled versions of these libs). We
should use this opportunity to reduce the brittleness of our configurations.
Of course this has to be balanced with pragmatics.
> > We have an opportunity here to establish
and adopt best practices.
> > We should take it. To that end, a stake has been put in
> > to define the naming and versioning conventions to be used. The
> > commons logging bundle follows those conventions. Of course,
> > ammend/change the conventions as it is early days for Orbit.
> Yes, and being ultra sensative to compatibility with previous
> versions is one "best practice"
> we should be exemplary in ... and an example of how to "transition
> names" would be one
> such case.
> > This line of discussion raises an interesting
question. Does the
> > originating project have any particular standing different then
> > rest of the consuming projects when it comes to bundling in Orbit.
> > My personal view is no, we are all just consumers and are all
> > working together to create a coherent and consistent solution
> > third party library problem. An approved library can be
> > to Orbit by any Orbit committer.
> Yes, any could commit, as long as others have veto rights as is
> required in Eclipse Foundation projects :)
> And, allowing any to commit also requires a very traceable history
> of what has
> been officially approved, which is why I think we need a
> log that points back to the original log showing approval.
> Or, at least, an easy to query bugzilla entry.
> For example, what if I wanted to ship a "product" or other
> source project that used javax.servlet and javax.servlet.jsp
> other than word of mouth, how could I verify that it's been approved?
I totally agree that we should be able to point to
the approval information. The best source of this information is
the Foundation's IP process and IPzilla. Orbit can duplicate that
information but it would not be authoritative. One thing that must
be absolutely guaranteed is that if it is in Orbit, then the Foundation
*must have* approved it for use by *some* project. Orbit changes
nothing wrt the IP process. Projects themselves still have to fill
out a contribution questionnaire and get approval to use a thrid party
lib. Orbit simply captures and shares the work that goes on after
approvals have been given.
> Also, I'm partially asking this question since
this project seems a
> little different from others in that others are not considered "official"
> until they are "released". Is there a similar "release
date" for Orbit?
> [Obviously, we could force there to be one, by saying so, but seems
> a bit odd, since
> the underlying project/products have already been released]. Or, are
> we in the odd postiion of saying these bundles are only released when
> an _Eclipse_ project that uses them is released?
Orbit should participate in Europa but you raise a
good point. Perhaps we have to come up with a way of identifying
bundles that are "good to go". If WTP (for example) wants
to do a release in January, they will want to go with good Orbit bundles.
Note that other projects (e.g,. Equinox/Bundles) have similar issues.
> In summary, my main concerns in these long note are
> 1. How to keeping binary compatibility with what has come before?
> 2. How to we provide documented traceabiltiy?
> Thanks for any ideas ... or, talk on the phone later in the week.
Sure. Its good to work through the issues here
if for nothing else to form a basis for a phone discussion.