[Biojava-dev] biojava 4 release planning

[Michael Heuer]

Spencer Bliven wrote:

> Since this is a major version, we should focus on refactoring projects which
> will alter the API. There are only a couple things I'm working on that fit
> that. #126 is a major undertaking and will probably happen for 5.0 at the
> earliest. The symmetry code will consist of adding features, so this could
> be slated for 4.1, as could DSSP (#112). Of course there's no harm in
> including them in 4.0 if they're done, but we shouldn't wait for them.
>
> I'll try to look through the issues and assign milestones for each, but what
> I see as important to finish is deciding the biojava3 issue (see other
> thread), finish logging (#155), and a minor project I've been working on to
> refactor the structure CLI code. Personally, I think mid November would be
> reasonable to shoot for. Then we can start on 4.1 development (with a 5.0
> branch for any api-changing commits).

+1


> On Fri, Oct 10, 2014 at 10:37 AM, Jose Manuel Duarte <jose.duarte at psi.ch>
> wrote:
>>
>> To me 1 month sounds a bit early. In any case to go with the "release
>> early, release often" philosophy, we can really try to push it soon, say in
>> a couple of months.
>>
>> What about setting a target date of December (before the 15th)? I think
>> that can be helpful for everyone involved to get ready for it.
>>
>> The milestone 4.0 in github doesn't show so much:
>>
>> https://github.com/biojava/biojava/milestones/BioJava%204.0.0
>>
>> But I think some other things are missing there, for instance
>> nice-to-haves in the structure module would be: improving structure
>> alignments (#126), reorganising symmetry code, finish secondary structure
>> implementation (#112)... All of these are of course optional, they can
>> always be pushed back if we can't reach them on time.
>>
>> As for core and other modules I really have no clue. It would be nice if
>> someone can say if there are plans to add new features there.

I will have a minor change to the sequencing module before 4.0, to
update the guava dependency version to 18.0.  I can get that in
quickly.


>> An important issue we should really address is eliminating the biojava3
>> naming that some packages now have. The reason behind those names is
>> apparently keeping compatibility with biojava legacy, but by now we can
>> probably do without that. I'd say simply eliminating the 3 would do the
>> trick. Otherwise take an approach like blast where they kept a blast+ and a
>> blast legacy. I'd favour simply eliminating the 3, it should help to keep it
>> simple.

I'm sorry, I don't believe we can do this.  The reason we still cut
new biojava-legacy releases is that lots of people still use that
code.

   michael