[Biojava-dev] version 3.1.0 plans and deprecation

[Andreas Prlic]

Hi Spencer,

in the past we have basically never fixed bugs on released branches. It was
easier to just fix the trunk and make another quick release. I suspect this
might not change also with the new semantic versioning conventions.

Having said this, it might be good to make it easier to create biojava
releases and set this up so more people can do this. So far Michael Heuer
and I are the only two people with the SSH keys required to push a release
to cloudeportal.open-bio.org, which is hosting our web site and Maven repo.

To make this easier, it would be great to move our Maven repo to one of the
public open source repositories, such as the Sonatype OSS repo. This could
also be a path for distributing biojava via Maven central.

Not having to update the wiki pages for every minor release might also
speed up the release process. Currently uploading javadocs and updating
links and wiki pages is the most time consuming part of a release. For
detailed release instructions see:

http://www.biojava.org/wiki/BioJava:Make_release

Andreas


On Mon, Apr 14, 2014 at 3:48 AM, Spencer Bliven <sbliven at ucsd.edu> wrote:

> To continue with the semantic versioning discussion, will we need to change
> our git conventions to match this? E.g. have  branches for both the
> major/minor/patch versions?
>
> -Spencer
>
>
> On Thu, Apr 3, 2014 at 12:24 PM, Jose Manuel Duarte <jose.duarte at psi.ch
> >wrote:
>
> > +1 to Andreas' comment
> >
> >
> >
> > On 02/04/14 23:00, Andreas Prlic wrote:
> >
> >> I do like semantic versioning and I believe it would make it easier for
> >> users to understand how significant changes are between releases.
> >>
> >> There is nothing preventing us from jumping to "4.0" instead of "3.1" .
> As
> >> such I'd say let's start to use semantic versioning starting with next
> >> release. This would make the next release the 4.0.0 release.
> >>
> >> That leaves the question what to do about your case, where you need to
> >> remove code due to the deprecation of code in an external library. Since
> >> we
> >> are making a major version change anyways, let's move forward fast and
> >> delete and replace the related code.
> >>
> >> Andreas
> >>
> >>
> >> On Tue, Apr 1, 2014 at 6:22 PM, Michael Heuer <heuermh at gmail.com>
> wrote:
> >>
> >>  Hello devs,
> >>>
> >>> Biojava has never followed the semantic versioning specification
> >>>
> >>> http://semver.org/
> >>>
> >>> in that MAJOR version is set in stone due to the abandoned biojava2
> >>> effort and binary incompatible changes have been allowed to take place
> >>> between MINOR version changes (and perhaps even between PATCH
> >>> versions, although I'm not sure I can find any examples).
> >>>
> >>> I need to make some changes to the org.biojava3.sequencing.io.fastq
> >>> package, e.g.
> >>>
> >>>
> >>> http://www.biojava.org/docs/api/org/biojava3/sequencing/
> >>> io/fastq/FastqReader.html#parse(com.google.common.io.
> >>> InputSupplier,%20org.biojava3.sequencing.io.fastq.ParseListener)
> >>>
> >>> because InputSupplier and related have been deprecated and scheduled
> >>> for removal from Guava.
> >>>
> >>> "This interface is scheduled for removal in June 2015."
> >>>
> >>> http://docs.guava-libraries.googlecode.com/git-history/
> >>> v16.0.1/javadoc/com/google/common/io/InputSupplier.html
> >>>
> >>>
> >>> 3.0.8 --> 3.1.0 has been proposed because some deprecated biojava3
> >>> code is ready to be removed.  I am wondering how I should coordinate
> >>> the changes to io.fastq, deprecate in 3.0.9 and remove in 3.1.0, or
> >>> deprecate in 3.1.0 and remove in 3.2.0?  Similarly in biojava-legacy,
> >>> deprecate in 1.8.6 and remove in 1.9 or deprecate in 1.9 and remove in
> >>> 1.10?
> >>>
> >>> Or should biojava3 at least move to semantic versioning from this
> >>> point forward and jump to 4.0 instead of 3.1.0?
> >>>
> >>> Thanks,
> >>>
> >>>     michael
> >>> _______________________________________________
> >>> 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
> >
> _______________________________________________
> biojava-dev mailing list
> biojava-dev at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/biojava-dev
>