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

Bump version to 0.8 #248

Merged
merged 1 commit into from
Sep 14, 2021
Merged

Bump version to 0.8 #248

merged 1 commit into from
Sep 14, 2021

Conversation

ViralBShah
Copy link
Member

@ViralBShah ViralBShah commented Sep 9, 2021

Bump version to 0.8 since we now have working CI now, with proper platform support, arm64 on win, and assorted fixes.

Bump the SOVERSION as well since we have some new exports and such.

@kargl
Copy link
Contributor

kargl commented Sep 10, 2021

If you're going to bump the version number, can I suggest that you look at issues 205, 206, and 206. Fairly, trivial patches.

@ViralBShah
Copy link
Member Author

ViralBShah commented Sep 11, 2021

Any chance you have patch files for these handy?

@kargl
Copy link
Contributor

kargl commented Sep 11, 2021

I barely know how to use git. I can clone things from github. I probably had patches 1.5 years ago when I opened the issues. Unfortunately, no one ever acknowledged the issues. So, things rot and get lost. I likely found the issues by comparisons between FreeBSD's libm and Openlibm. Openlibm is derived from FreeBSD. A diff might be fruitful.

@ViralBShah
Copy link
Member Author

ViralBShah commented Sep 11, 2021

Sorry about the silence. I periodically collect your patches from the issues and apply them. Issues that are not relevant, I do close them.

In general in Julia, we no longer use openlibm for much anymore. I just like to keep this project going since it is valuable to have it as an independent libm.

@ViralBShah
Copy link
Member Author

ViralBShah commented Sep 11, 2021

Note: need to rebase to master for win64 arm.

Bump the SOVERSION as well since we have some new exports and such.
@ViralBShah
Copy link
Member Author

I'm going to merge this today. We can always go to newer versions - 0.9, 0.10, 0.11, etc. as other fixes pour in.

@ViralBShah ViralBShah merged commit ed7aea3 into master Sep 14, 2021
@ViralBShah ViralBShah deleted the vs/0.8 branch September 14, 2021 16:35
@nalimilan
Copy link
Contributor

nalimilan commented Sep 18, 2021

New exports don't require a SOMAJOR bump.

@ViralBShah
Copy link
Member Author

Do they require an SOMINOR bump?

@nalimilan
Copy link
Contributor

Yes. But bumping SOMINOR isn't a problem. What's annoying is that bumping SOMAJOR forces distributions to recompile all packages that depend on openlibm.

@ViralBShah
Copy link
Member Author

I can never remember what to do when. Would be nice to clearly note in the Makefile.

@ViralBShah
Copy link
Member Author

Should we make another release resetting the SOMAJOR and bumping the SOMINOR?

@nalimilan
Copy link
Contributor

I can never remember what to do when. Would be nice to clearly note in the Makefile.

Well it already says:

# Do not forget to bump SOMINOR when changing VERSION,
# and SOMAJOR when breaking ABI in a backward-incompatible way

This is the same as semantic versioning actually.

Should we make another release resetting the SOMAJOR and bumping the SOMINOR?

What we could do is make more releases with the old SOMAJOR version (3), and the day we break the API, skip SOMAJOR 4 (which has already been used in the release following this PR) and go directly to 5. But I'm not sure it would be worth it, and we're likely to forget to skip 4, which would really be problematic.

@ViralBShah
Copy link
Member Author

What if we just leave it as is now, and be more careful in the future?

@nalimilan
Copy link
Contributor

Yeah I guess there's no better choice... :-/

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

Successfully merging this pull request may close these issues.

3 participants