Release v1.0

[nickrobinson251]

The last breaking change to this package was >1 year ago (not counting adding new exports it was a really long time ago). That's about as stable as it gets :)

Tagging 1.0 reflects this stability, and gives us finer grained control over version bumps.

[nalimilan]

Yeah, why not. Though tagging 1.0 will force all dependencies to update their version bounds, so from a convenience perspective we'd better not tag 1.0 until we actually have breaking changes.

[pdeffebach]

Can we do an intermediate release to get passmissings to users?

[nalimilan]

You mean skipmissings? passmissing is already released AFAICT. Feel free to make a PR to bump the version.

[pdeffebach]

Sorry, skipmissings. Cool will work on that.

[bkamins]

It would be ideal to revive this proposal. When we tag DataFrames.jl 1.0 version it should depend on Missings.jl 1.0 (possibly allowing backward compatibility but this is a detail).

What do we need in Missings.jl to go out with 1.0 release?

[nalimilan]

I kind of hoped we would have a few breaking changes before tagging a breaking release, but the API is desperately stable...

[quinnj]

That would be ideal, but I also think it's still worth it to just tag 1.0. Having the full flexibility of semver I think it more beneficial long-term than current dependendees just need to bump a number even though it's non-breaking.

[pdeffebach]

The only open PR / feature is #122 to add "spreadmissing".

This feature, and a non-spreading version, will make things like correlation between vectors with missing values easier. DataFrames might eventually use this, but it's certainly not going to happen before DataFrames goes 1.0 so there isn't a huge rush.

Another major goal might be to move passmissing into base, rename it to lift, and have better support for keyword arguments. Base devs might be supportive because it means they wouldn't have to add methods for missing as much.

[bkamins]

renaming it to lift in Base is probably unlikely as lift is considered to general name as far as I remember the discussion we had last time about it.

[nalimilan]

Anyway we don't expect breaking changes to passmissing, right? Keyword arguments currently throw an error so we can add support for them at anytime. And TBH I'm not a fan of lift, that's not very explicit and I don't think people working with statistical missing data are used to it (that's essentially a C# name AFAIK).

So I'm fine with tagging 1.0.

[bkamins]

bump - what do we do with this?

[nalimilan]

Not sure. There's been some discussion about the fact that the current skipmissings interface doesn't work with cor, cov, etc., so maybe it would have to be changed. Maybe we'd better sort this out before tagging 1.0 (especially since we don't have any changes to release at all currently)?

[bkamins]

OK. I just wanted to have all DataFrames.jl dependencies to hit 1.0 :). But we can live with this. I assume what is going to change till 1.0 does not affect DataFrames.jl internals.

[nickrobinson251]

For what it's worth (since i'm not a big contributor here), i'd happily see the current version tagged at 1.0, and we can have v2.0 for any future changes (which seem to be a way off, since they're not currently in progress)

[bkamins]

The point is that we re-export Missings.jl in DataFrames.jl. Therefore I would preferably have Missings.jl tagged 1.0.

@nalimilan - do you see a realistic timeline to clean up the discussions on skipmissings in Missings.jl?

[quinnj]

I think we should tag 1.0 unless we think someone is going to do some breaking work on, e.g. skipmissings in the next week or so.

[pdeffebach]

This is my bad. I started #122 then didn't finish it.

I'm not sure I'm the best person to do that PR, tbh. It's pretty low-level and there might be performance things. But I think it's definitely the way forward.

I guess what I'm saying is I can work on it this week, but if we really want it in before 1.0 maybe Milan or Jacob should start a new PR that does things "right" and get it merged in the next two or so weeks.

If not, then we can release 1.0 and work on that in a longer timeline.

[quinnj]

I'm happy to review/help if needed, though @nalimilan is probably more aware of all the issues going on. If he can't help though, I can carve out some time over the next week to push if that's what we need/want.

[nalimilan]

Finishing the spreadmissings PR isn't required to tag 1.0, as it can be added later. What has to be decided is whether we're reasonably sure that skipmissings is useful in its current form. If not, we could deprecate and/or remove it until we have a working solution for cor, cov, etc.

[quinnj]

What's the issue w/ skipmissings and cor/cov? They don't work on length-less iterators? Can we update them to work? Or do we need an eager skipmissings equivalent? Is there discussion on htis somewhere?

[pdeffebach]

It doesn't work with Iterators at all.

Maybe we should make skipmissings views?

[nalimilan]

The discussion is at https://github.com/JuliaLang/Statistics.jl/pull/34 (and older linked issues). These are quite complex questions that should rather be discussed there.

[bkamins]

My question is:
do we believe that skipmissings will stay in the long run. If not (and from the discussion I feel that this is the case from the discussion above) then I would open a PR that would add a deprecation warning that skipmissings might be removed or changed in the future and bump the version to 1.0.

@nalimilan + @pdeffebach : can you say what you think?

[nickrobinson251]

https://github.com/JuliaData/Missings.jl/releases/tag/v1.0.0