Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Roadmap to 1.0 #162

Open
2 of 4 tasks
DilumAluthge opened this issue Nov 20, 2019 · 8 comments
Open
2 of 4 tasks

Roadmap to 1.0 #162

DilumAluthge opened this issue Nov 20, 2019 · 8 comments

Comments

@DilumAluthge
Copy link
Member

DilumAluthge commented Nov 20, 2019

What needs to be done before we can release JLD2 version 1.0.0?


Breaking changes we want to make before releasing 1.0:

  • none

Nonbreaking changes we would like to make. These can be made after releasing 1.0:

  • Some way to control the compression from @save, e.g. Global compress option #133
  • Time/filesize profiling in typical workloads
  • Compression that reduces the file sizes more
  • Implement some variant of addrequire
@alyst
Copy link

alyst commented Nov 20, 2019

It would be nice to address #133 or have some way to control the compression from @save.

It would also be nice to do time/filesize profiling in typical workloads, because I have an impression that JLD2 is not very fast, and the filesizes are larger than alternatives (serialization, .RData files).
Also, enabling compression didn't reduce the file sizes as much as I have hoped.

@timholy
Copy link
Member

timholy commented Nov 20, 2019

Another thought would be implement some variant of addrequire. I don't want to portray this as essential because no matter what, I think we have to support files written in older formats whenever we move to 1.0.

@DilumAluthge
Copy link
Member Author

DilumAluthge commented Nov 20, 2019

All of those are nice and good ideas, but none of them are breaking, right?

The only reason to delay the release of 1.0 is if there are breaking changes we want to make. Once we release 1.0 we can still make as many non-breaking changes as we want.

@timholy
Copy link
Member

timholy commented Nov 20, 2019

I don't think any are breaking.

@alyst
Copy link

alyst commented Nov 20, 2019

Compression configuration is theoretically API-breaking. It would be nice (IWBN) to decide what to do with it before releasing 1.0. If the planned change would not break the API, it could be done after 1.0.

There could be some storage format tweaks that improve the performance (e.g. #135) or resolve data corruption issues (e.g. #163), IWBN to introduce the changes before 1.0 as well.

Maybe the current issues should be triaged as 1.0-blocking/nonblocking? Even if the fixes would be non-breaking, IWBN to tag 1.0 as a declaration of package maturity.

@alyst
Copy link

alyst commented Nov 20, 2019

Also, #126 & #151 were non-breaking, but many JLD2 files created before 0.1.6 are unusable because of the wrong type names.
This is something that should be avoided for files created with JLD2 1.0+.

@cossio
Copy link

cossio commented Apr 22, 2022

Is there anything holding back a 1.0 release at this point?

@JonasIsensee
Copy link
Collaborator

As an update on this:
The compression part of the library needs a reworking. This can't be done without breaking API changes.
That is the main thing holding back 1.0 at this point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants