Hi all,

Graeme raised the question of whether we should try to separate framework
and connectors into separate releases.  I'm creating a new thread for
discussion of that proposal.

To summarize the proposal, we'd have a separate release cycle for the
framework and each of the connectors.

The benefits:

- Much easier to incorporate new connectors into the project
- Lots of small releases rather than one big one
- A new connector release would not necessarily be needed for every major
framework release (although we may well want to do it as a matter of policy
in any case -- see the technical note below)

The downsides:

- Framework tests that don't require actual shipping connectors to exercise
framework features are almost non-existent
- Getting a voting quorum to release a new revision of a connector that is
lightly used might be a significant challenge
- It becomes much harder to make global changes that extend the connector
APIs, because there may well be a dozen votes or more as a result
- Deployment is far more difficult; you'd effectively need an installer for
each connector package that you'd run to install it into the
example(s)(?).  All the examples would need to change fundamentally as a
result, as would the documentation.

** The technical complication is that for connectors we've made much use of
the interface/abstract base class metaphor to keep backwards compatibility
for connector methods.  This works fine IF you rebuild your connector every
time the base class changes, but if you don't you will likely get linkage
errors when you run.  So, we reasonably should expect to rerelease all
connectors on every framework release anyhow.

Thoughts?

Karl

Reply via email to