What used feature in BioSequences v3 requires Julia v1.5?

[CiaranOMara]

What used feature requires Julia v1.5?
https://github.com/BioJulia/BioSequences.jl/blob/9918be2cea9f293d0b1657d4bce21c788a22e6f5/Project.toml#L15

[jakobnissen]

The use of bitreverse, which was added in 1.5.
Now, one could argue that we might as well roll our own implementation and continue to support v1.0, and we certainly could (indeed, Base's implementation was suggested by me, who copied it from Sabrina's implementation in Twiddle.jl which is already a dep of BioSequences).

However, I would argue that it's a good idea that we continually drop support for older, unsupported Julia versions. It will be easier to write code and maintain it that way, since we only need to test on current and LTS versions and our test suite will be quicker.
Also, I think it does not cause any real issues with reproducability/stability. For new projects, all users should use a supported version of Julia, anyway. In case the user wants to run with an old version of Julia, for example if reproducing some old study that used an ancient version of Julia, they would not be using recent versions of BioSequences.jl, anyway.

What versions to support is certainly up for debate though. Are there any compelling reasons to support old versions of Julia on new versions of BioSequences?

[TransGirlCodes]

I agree with this. It's also worth noting that if someone had something they held rather critical that depended on older julia / BioJulia API's, then they could also use jvm and thank's to julia's package manager and project structure, simply have an older setup.

[kescobo]

oh hey @TransGirlCodes , lovely to see you here :-)

Sorry for all the recent tagging 😳

[CiaranOMara]

I think I've mentioned this somewhere else. I don't agree with arbitrarily dropping compatibility. I think the first functional version should be tested and recorded in the compat section. And ideally a reason for incrementing the compatibility version is somehow recorded.

Regarding development, I think the current LTS is the barrier for which new language features will be adopted/used in a BioJulia package. Generally, I don't think it is a good idea to develop new code in an old way. There needs to be a good reason to write code in an old, less convenient way.

At the time I asked this question, I was tracking down a compatibility issue, which was resolved by BioJulia/BioSequences.jl@3c8f501.

[jakobnissen]

Thinking a bit more about it, I agree. We should not drop compat for no reason at all, other than that we don't care to run CI on old versions.

Practically speaking, compat is usually dropped because the developer wants to use some new feature in Julia. So: Suppose a developer is working on a package that works with Julia 1.0, but wants to use a feature introduced in 1.7. What should they do?

I haven't thought much about this, but my intuition tells me it's a good idea to have a rule of thumb that says that we support the LTS, unless we can justify in the concrete case that there are important features which is difficult to achieve on the LTS versions. We want to also support older versions, but not if it comes at the expense of using nifty new Julia functionality that makes development easier.

So: What do you think of this proposal, summarized as:

• We make efforts to support LTS, and only require a newer version if supporting LTS becomes particularly hard due to some important new feature we can't re-implement and which we really need
• We support older-than-LTS versions only if it does not constrain our development. If the dev wants to use features only present in the LTS but not the oldest compat, they should just bump compat to LTS

[kescobo]

Perhaps more succinct:

1. Don't drop compat for older julia versions without a reason.
2. The reason should be compelling for dropping compat for LTS
3. The reason can be merely convenience for dropping compat for pre-LTS

?