Tag DSP v1

[dlfivefifty]

There hasn't been a breaking change in 3 years... probably a good time to tag 1.0

[wheeheee]

There will be some in 0.8. You can find some of them in the milestone here: https://github.com/JuliaDSP/DSP.jl/milestone/3

[dlfivefifty]

I would say v0.8 should just be v1.0 in that case.

Using v0.x longer than necessary has two problems: (1) it marks the package as unstable, which in this case it clearly isn't and (2) you cannot take fulll advantage of semantic versioning.

[dlfivefifty]

And (3) it annoys me slightly when my Project.toml files for a v1.x package depend on a v0.x package 😅

[martinholters]

The absence of breaking changes has primarily been due to overall slow development. I'm not sure that should be taken as a sign of stability.

That said, I agree that we should aim at v1.0 in the foreseeable future. My preferred path forward would be to tag v0.8 soon(!), wait for a few months, say, whether anything severe shows up, and if everything seems calm, tag v1.0 after removing deprecations.

[dlfivefifty]

I would take the lack of breaking changes as the definition of stability. I don't think "v1.0" means the finished product, and if there are major issues there can always be a v2.0...

[martinholters]

I would take the lack of breaking changes as the definition of stability.

What about breaking changes we are aware must happen but haven't come around to executing?

Also, there has been a breaking change at least almost a year ago (#458), which has been sitting around for almost three years. Just because we waited for a long time to do a breaking release doesn't mean there were no breaking changes in the pipeline. Would have been funny to release v1.0 at some point knowing the release after would probably have to be v2.0.

[dlfivefifty]

I don’t think it’s strange at all if v2 is the next release after v1, according to the principles of semantic versioning.

there will almost always be breaking changes in the pipeline (unless the package is mothballed)

[martinholters]

If I got the regex right, there are a total of 64 Julia packages registered with v2.0.0 immediately following v1.0.0. So while perfectly legal, it's at least unusual.

What would you consider a criterion for not calling a release v1.0?

[dlfivefifty]

I would say the criteria is that the interface is unstable in the short term. I.e. if v2.0 will be released within weeks or a month.

But if v1.0 is going to last 3 years and v2.0 is the next release in 2028, then that is probably fine 😀

[martinholters]

Agreed. Trouble is: If at least some of the maintainers are actively working on breaking changes to land in the foreseeable future, they won't release v1.0. If they then stop working on DSP.jl for whatever reason, they won't think "oh, I don't find time to invest into DSP.jl anymore, so let me see to do a release." And that's what happened, unfortunately. (With "some of the maintainers" definitely including me.)

Yes, if we had known in 2022 it took us to Dec. 23 to merge #458, and then another year with more breaking changes trickling in without doing a release, we could have tagged v1.0 in 2022. But we didn't know, so we didn't tag.

However, I now think that 0.8 is indeed coming close -- feel free to bump the issues/PRs in https://github.com/JuliaDSP/DSP.jl/milestone/3 in case progress stalls. And three months after 0.8, please do come back and ask about v1.0 if that still hasn't happened.

[dlfivefifty]

Yes I understand. Just feel like some packages end up in v0.x forever because people have an illogical fear of v2.0... probably in part because Julia will probably never do v2 😅

[dlfivefifty]

Actually.... downstream I only ever use conv. What would you say to moving that out to its own package (Convolutions.jl) for v1?

[wheeheee]

I don't see a problem with that but what organisation should that be under? It might also make sense to ask around ImageFilters because they already have a slicker API (I know, correlation not conv, but...) and multithreading figured out.

[dlfivefifty]

JuliaDSP organisation?

[wheeheee]

I was thinking that convolutions aren't a DSP-only thing, and currently there aren't a lot of features, so claiming that package name might bar others from putting it to another (more ambitious / better?) use. But anyway I'm opening a draft PR to put that code into a submodule, to see if it's something we want.