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

Cleanup round (no functional inpact) before releasing v0.4.0 #55

Closed
aklomp opened this issue Nov 16, 2019 · 4 comments
Closed

Cleanup round (no functional inpact) before releasing v0.4.0 #55

aklomp opened this issue Nov 16, 2019 · 4 comments
Milestone

Comments

@aklomp
Copy link
Owner

aklomp commented Nov 16, 2019

I would like to release a new library version (v0.4.0) which puts a tag on the code that everyone has been using for the last few years. This will make room to introduce some breaking changes from here on forward.

However, before we can release, the code is in need of a cleanup round. The codebase has accumulated a lot of patches from various contributors, in various different styles. This has led to some inconsistencies with how things are done, as well as diminished the quality of comments, and accumulated dead code.

Objective: push a set of commits which fix many of these issues, without introducing any functional changes. The library code, as seen by the compiler, must remain unchanged from what it is now, to avoid regressions for anyone switching to this new version.

  • Fix some trivial whitespace issues (wrong indent, trailing whitespace, etc).
  • Reword some comments for clarity.
  • Split some monolithic code files into smaller parts, to conform to the general style.
  • Uniform style for function declarations, bodies of if statements, etc.
  • Remove dead code.
  • Remove the now unnecessary CMPGT macros and friends.
@aklomp aklomp added this to the v0.4.0 milestone Nov 16, 2019
aklomp added a commit that referenced this issue Nov 19, 2019
Do a cleanup round before tagging the next version. To prevent accidental
regressions, the cleanups in this commit set should introduce no externally
visible functional changes.
@aklomp aklomp closed this as completed Nov 19, 2019
@BurningEnlightenment
Copy link
Contributor

Maybe it's time for a 0.4.1/0.5.0/1.0.0 release due to the same reasons?

@aklomp
Copy link
Owner Author

aklomp commented Jun 6, 2022

Yes, I intend to do a new release once everyone is happy with the cmake stuff. The reason is that I might want to make some API changes, like remove the avx codec (which is identical to ssse3 right now) and rethink the runtime feature detection a bit.

@BurningEnlightenment
Copy link
Contributor

BurningEnlightenment commented Jun 6, 2022

Can you create a meta-issue (and perhaps a milestone) to track the open work?

@aklomp
Copy link
Owner Author

aklomp commented Jun 6, 2022

I created #90 to release v0.5.0, and added a milestone to tag issues with that version.

I won't be releasing v1.0.0 just yet because I am seriously unhappy with the API for this library. The issues raised in #65 are real. I'd like to get rid of the codec "forcing" stuff and replace it with a form of runtime discovery of supported/runnable codecs.

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

2 participants