[ENH]: Support for Power 2013 coordinates #245
No reviewers
Labels
No labels
CRITICAL
Stale
WIP
bug
concept
coordinate
dataset
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
maintenance
maps
marker
mask
on hold
parcellation
preprocess
question
ready
storage
template-space
triage
wontfix
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
juaml/junifer!245
Loading…
Reference in a new issue
No description provided.
Delete branch "feature/power-2013"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Are you requiring a new dataset or marker?
Which feature do you want to include?
We don't yet have the Power 2013 coordinates in-built. This will be a great addition.
How do you imagine this integrated in junifer?
As other in-built coordinates.
Do you have a sample code that implements this outside of junifer?
No response
Anything else to say?
No response
Codecov Report
100.00% <ø> (ø)93.05% <33.33%> (-0.06%)Flags with carried forward coverage won't be shown. Click here to find out more.
95.34% <33.33%> (-4.66%)gh-pagesat 2023-09-06 09:39 UTCThis is a backward's incompatible change. What about a deprecation cycle?
If I remember correctly, we can use functions to "load" coordinates/masks. Or we can implement it in a way that when someone uses "Power" it triggers a deprectation warning during a few release cycles. (We need to define).
That is true. I went with the breaking change as we are still not v1.0.0 . But, I don't mind putting a deprecation notice.
So, I'll put a deprecation notice stating that we'll remove it in the next release.
I was thinking to use something like this: https://deprecation.readthedocs.io/en/latest/
while encapsulating the "power" in a function so we can keep track of the deprecation cycle. Otherwise we need to memorise stuff.
This would require us to include another dependency for junifer and for one release cycle I don't think it's worth it. I think this makes sense once we start having objects which require backwards incompatible changes and that would happen after v1.0.0 IMO.
We'll create another PR for that. I don't want to have this messages all around. And this will happen quite often i'm afraid.