You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to propose that we make our first Java 11 release and call it 6.1.0. That will mean that BioJava won't be possible to use under a JRE 8 from that moment on.
On Fri, Jul 15, 2022, 6:45 PM Jose Manuel Duarte ***@***.***> wrote:
I'd like to propose that we make our first Java 11 release and call it
6.1.0. That will mean that BioJava won't be possible to use under a JRE 8
from that moment on.
Is there anything against that?
—
Reply to this email directly, view it on GitHub
<#1035>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABLFC4BYWABVQ75UJ3TUORTVUHSYBANCNFSM53XA3ARA>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
I support the idea in principle. But I prefer deferring the dependency change only to be in synchrony with the next big structural change (i.e. BioJava 7.0).
If there any reason we should drop java 8 support?
Take into account that java 8 is now 3 LTS versions behind the latest LTS version (11, 17 are the newer ones). So we would only be upgrading to the last-but-one LTS.
I support the idea in principle. But I prefer deferring the dependency change only to be in synchrony with the next big structural change (i.e. BioJava 7.0).
I wouldn't be opposed to releasing this upgrade as 7.0. Then we can take the opportunity to bring in some breaking changes. For instance dropping some modules, see #975
As long as the library supports the newer java versions, then I guess my
question would be better framed as: why remove java compatibility if it's
not necessary?
On Mon, Jul 18, 2022, 6:17 PM Jose Manuel Duarte ***@***.***> wrote:
I support the idea in principle. But I prefer deferring the dependency
change only to be in synchrony with the next big structural change (i.e.
BioJava 7.0).
I wouldn't be opposed to releasing this upgrade as 7.0. Then we can take
the opportunity to bring in some breaking changes. For instance dropping
some modules, see #975 <#975>
—
Reply to this email directly, view it on GitHub
<#1035 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABLFC4E6LIGLIX5SMEFKSOLVUXJY3ANCNFSM53XA3ARA>
.
You are receiving this because you commented.Message ID:
***@***.***>
See some reasons in the post I linked above. For instance this point:
using an old software stack can severely limit your selection of useful third-party libraries and/or tools. A given library that you really need might require a more recent Java version or (possibly even worse) a library that you already use increases it's Java version requirement with a new major release (leaving you stuck with an old Java version and an old software version that might be missing important bug fixes).
This is a very real concern for us. Some libraries that we depend on have moved to java 11.
It's not specially urgent but at the same time I don't want to leave the problem open for too long. I'll propose to do the release no later than the end of January 2023. I'll set that date in the milestone.
@josemduarte Thank you for the reminder.
It seems that #993 will not catch BioJava 7.0.0.
Let's continue the discussion stress-free from the time constraint and aim at a better comprehensive redesign of the interfaces by BioJava 7.5 or 8.0 (whichever comes first).
Activity
emckee2006 commentedon Jul 15, 2022
heuermh commentedon Jul 16, 2022
+1 from me
aalhossary commentedon Jul 16, 2022
josemduarte commentedon Jul 18, 2022
Take into account that java 8 is now 3 LTS versions behind the latest LTS version (11, 17 are the newer ones). So we would only be upgrading to the last-but-one LTS.
In any case, there are many reasons for upgrading, this posts does a good summary: https://stackoverflow.com/a/58992471/3914327
josemduarte commentedon Jul 18, 2022
I wouldn't be opposed to releasing this upgrade as 7.0. Then we can take the opportunity to bring in some breaking changes. For instance dropping some modules, see #975
emckee2006 commentedon Jul 18, 2022
josemduarte commentedon Jul 18, 2022
See some reasons in the post I linked above. For instance this point:
This is a very real concern for us. Some libraries that we depend on have moved to java 11.
josemduarte commentedon Oct 24, 2022
Ok given the discussion here it seems prudent to use
7.0.0for the new version. I will change the milestone.6.1.0will be the next release, still based on java 8 with a few fixes and additions.aalhossary commentedon Oct 24, 2022
@josemduarte When is 7.0.0 expected?
I have one or two open pull requests that I couldn't handle yet because of the pressure of my new work.
josemduarte commentedon Oct 24, 2022
It's not specially urgent but at the same time I don't want to leave the problem open for too long. I'll propose to do the release no later than the end of January 2023. I'll set that date in the milestone.
josemduarte commentedon Jan 30, 2023
A reminder to everyone that tomorrow is the date set for the 7.0.0 (java 11 based) release. I'll be merging PRs and producing the release tomorrow.
aalhossary commentedon Jan 30, 2023
@josemduarte Thank you for the reminder.
It seems that #993 will not catch BioJava 7.0.0.
Let's continue the discussion stress-free from the time constraint and aim at a better comprehensive redesign of the interfaces by BioJava 7.5 or 8.0 (whichever comes first).
josemduarte commentedon Jan 31, 2023
BioJava 7.0.0 is out now