On Mon, Oct 7, 2013 at 7:35 AM, Egon Willighagen <[email protected]
> wrote:
> On Mon, Oct 7, 2013 at 1:30 PM, Rajarshi Guha <[email protected]>
> wrote:
> > I have to say though - if a functionality or package is used by one or
> two
> > people, I do not see it as sufficiently vital to the CDK that it be
> included
> > in the codebase. Why not push those types of things to a contrib
> repository?
> > Or include them as contrib jar files?
>
> Diverging versions at least.
>
> But I am worried... we don't know who uses what. We only find out when
> people publish things, and who of use ever did a proper analysis of
> which CDK classes are being used in what paper, and in what
> unpublished work? I think our best guess is where we received bug
> reports... I think that the research field is mostly interested in
> small molecules is a biased analysis.
>
I'm not sure as to a better way, beyond limiting the entry of new things
that are not sufficiently general or fundamental (yes, IPolymer would
satisfy both these requirements).
In terms of clean of unused features, there is not technical solution I can
see. I think the process would be
* Mark class(es) as @deprecated
* Announce imminent removal
* Remove it from the API into an external JAR (say deprecated.jar)
* Over time either remove it from deprecated.jar or just let it wither
--
Rajarshi Guha | http://blog.rguha.net
NIH Center for Advancing Translational Science
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Cdk-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/cdk-user
