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

Release 1.0 #467

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Release 1.0 #467

wants to merge 1 commit into from

Conversation

oxinabox
Copy link
Member

Noone wants to change FowardDIff.
It is stable.
Even if one does want to change ForwardDiff, noone wants to change the API in a breaking way.

@ChrisRackauckas
Copy link
Member

I'd say we do #419 and #463, which I don't think are actually breaking changes, but can be considered breaking changes, and we can call that v1.0. Then, once it's v1.0, I'd say we can document the Dual number interface, #379 because I'd hope no one would ever change that.

I'd like to get @KristofferC and @jrevels 's input though. But I think it's pretty safe to say, ForwardDiff works and if you want a very different AD then make a new package.

@oxinabox
Copy link
Member Author

I agree with those 2 PRs.

@codecov-commenter
Copy link

codecov-commenter commented Aug 27, 2020

Codecov Report

Merging #467 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #467   +/-   ##
=======================================
  Coverage   87.31%   87.31%           
=======================================
  Files          10       10           
  Lines         757      757           
=======================================
  Hits          661      661           
  Misses         96       96           

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c4487d5...b8265b8. Read the comment docs.

@fredrikekre
Copy link
Contributor

Please don't make a non-breaking 1.0.0 release.

@oxinabox
Copy link
Member Author

Its an unfortunate concisquence of julia's semver extension that 1.0.0 is always considered breaking.
So if one realises a package that is pre-1.0.0 is actually stable one has to delcare a breaking release to indicated that there will not be many breaking releases in the future.

But in this case I am kind of happy to have it considered breaking because #463 is borderline breaking.
Probabably fine for most uses, but I do know that sometimes people do construct duals directly, for better or worse.

@cossio
Copy link
Contributor

cossio commented Sep 12, 2021

Something holding this?

@KristofferC
Copy link
Collaborator

If someone wants to do this they need to make a corresponding change to the registry that allows ForwardDiff 1.0 for those packages that are currently claiming compatibility with ForwardDiff 0.10.

@oscardssmith
Copy link
Member

1.0 has already been tagged.

@oscardssmith
Copy link
Member

I don't know how to read.

@oscardssmith oscardssmith reopened this Sep 2, 2022
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.

None yet

7 participants