[Biojava-dev] BioJava code freeze, modularization and action items for sub modules

[Mark Schreiber]

I would agree with Richard on this. I think the changes being proposed
are not compatible with the current API. There are a couple of things
wrong with the current model (such as the Feature, Strand, Location
issues). There are also several areas where best-practices of the past
(parts of BioJava are 10 years old) are not considered best practices
now (some like Singletons are often thought of as anti-patterns these
days).

Add to that the fact that we have never been truly backwards
compatible (expept maybe 1.3 and 1.3.1 ?)  and I think we can
justifiably try and avoid the claim that BJ1.7 should be backwards
compatible.  We can continue to make older Jars available for people
who need them although most likely people who have a need for legacy
support already have the Jars that they need bundled up with their
apps. Shared libraries have very much fallen out of favor in recent
years in almost all languages and system wide classpaths are asking
for trouble.  Hard-drives are cheap so it is no big deal to have a
dedicated version of the BioJava jar bundled with each app that needs
it.

We could adopt the idea that backwards compatible builds get
minor-version numbers eg 1.1 while other builds get major version
numbers. I guess this would mean we are at BioJava 7 ?

Backwards compatibility would be great to have but not if the effort
required hinders innovation.

- Mark

On Tue, Aug 25, 2009 at 12:32 PM, Richard Holland
<holland at eaglegenomics.com> wrote:
>>
>>
>> What I mean is that we should try not to disrupt things as much as is
>> reasonable. I am all for a pragmatic approach. While trying to be
>> conservative I guess refactoring should be discussed on a case by case
>> basis. To give an example: an area where I am supporting re-factoring
>> is the blast parser. The package name is confusing and we probably
>> need some code changes to expose more details of the parser. Are you
>> thinking of any other situtations, where you think breaking backwards
>> compatibility will be inevitable?
>
> Almost all the parsers would fit this category, as would any realistic attempt to 'fix' the sequence model by moving bits of the APIs around (for instance, Sequences have Features which have Strands, but Locations do _not_ have Strands - which is all wrong, because Strand is a Location-level concept, not a Feature-level concept).
>
> My original plan was to not even attempt to make new versions backward compatible, and instead to have a separate module which coerced the new objects into complying with the old API interface declarations (by using the facade model).
>
> cheers,
> Richard
>
>> Andreas
>>
>> _______________________________________________
>> biojava-dev mailing list
>> biojava-dev at lists.open-bio.org
>> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>
> --
> Richard Holland, BSc MBCS
> Operations and Delivery Director, Eagle Genomics Ltd
> T: +44 (0)1223 654481 ext 3 | E: holland at eaglegenomics.com
> http://www.eaglegenomics.com/
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev