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

[Jules Jacobsen]

I think Mark has a good point here - there are certain aspects of
BioJava which are considered to be un-necessarily over-complicated and
these things have been deal-breakers for the people concerned - I
remember a couple of cases from the EBI where they have implemented
their own system instead of using and supporting BioJava.

Fixing areas of confusion, simplifying and moving forwards without
maintaining backwards-compatibility might be a good idea for
increasing user numbers and elevating the general perception of the
project, whilst potentially risking alienating some existing users.

I think his idea of maintaining compatibility within point releases
and stating that full version releases may not have backwards
compatibility would make it clearer for users as to what to expect
from a release. It may also help the developers stay on track with the
task and general design focus for that release by constraining them to
the current system during a point release whilst highlighting
confusing areas which can be dealt with in a more satifsfactory manner
in the next full release.

 Jules

On Tue, Aug 25, 2009 at 7:58 AM, Mark Schreiber<markjschreiber at gmail.com> wrote:
> 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
>
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>



Jules Jacobsen

UniProt-PDB Integration
EMBL-EBI
Wellcome Trust Genome Campus
Hinxton
Cambridge
CB10 1SD
UK