chore: start renaming as.directed() and as.undirected() to `as_di…#1513
chore: start renaming as.directed() and as.undirected() to `as_di…#1513aviator-app[bot] merged 3 commits intomainfrom
Conversation
Current Aviator status
This PR was merged using Aviator.
See the real-time status of this PR on the
Aviator webapp.
Use the Aviator Chrome Extension
to see the status of your PR within GitHub.
|
aviator-app
bot
force-pushed
the
as.directed
branch
from
84f7cc4 to
2eb903b
Compare
|
This pull request failed to merge: some required checks failed. After you have resolved the problem, you should remove the Failed checks: Check ubuntu-20.04 (oldrel-4), Check ubuntu-20.04 (release), Check ubuntu-20.04 (oldrel-3) |
…rected()` and `as_undirected()`
aviator-app
bot
force-pushed
the
as.directed
branch
from
a22bb97 to
e44c2a4
Compare
|
@maelle many thanks for your invaluable work on the igraph package, which remains a vital part of the computational research infrastructure for my group's work in neuroscience. As a long time user of igraph in my own packages, I was wondering if you could advise on protocol for this kind of renaming. In checking my package nat for CRAN I received a deprecation warning for
AFAICS the deprecation notice (which now triggers a warning in my tests / in some of my functions) was introduced at the same 2.1.0 release as the actual function name change and was not documented in the release notes or the package changelog. I would have expected a potentially breaking change like this to have more signalling but perhaps this is all according to protocol – I appreciate that staging changes across multiple versions can be a pain, but in the past igraph did signal such changes well in advance. For myself I have tried to support end users on old versions of igraph back to 1.1 (because our package is often run on servers that we don't control with older installations) but I will now have to choose between a sudden >=2.1.0 dependency or wrapping use of newly renamed functions in conditionals based on the installed igraph version. Thanks for any input and of course thank you again for your contributions to the FOSS ecosystem. |
* as.directed, as.undirected, graph * decided to wrap them so we don't have to fast forward igraph dependency to >=2.1.0 from >=1.0 * had to remove the explicit function imports (because we don't know which to import) * note that I also had to make an example conditional based on the installed version for the same reasons * see also igraph/rigraph#1513
* as.directed, as.undirected, graph * decided to wrap them so we don't have to fast forward igraph dependency to >=2.1.0 from >=1.0 * had to remove the explicit function imports (because we don't know which to import) * note that I also had to make an example conditional based on the installed version for the same reasons * see also igraph/rigraph#1513 * also fix some 1.8 conflicts when cherry-picking
|
👋 @jefferis! Thank you for your feedback. An admin note: In the future, please open a new issue referencing the old PR, as it is easier for the comment to not fall through the cracks. You can control lifecycle's verbosity locally in the tests and in your functions by setting an option: https://lifecycle.r-lib.org/reference/verbosity.html However it's true it seems this was missed in the release notes, sorry about that. Also note that the deprecation level will increase over time, at some point igraph will give a warning when using For context, we've been renaming functions to follow snake-case for more consistency. |
|
@jefferis: Happy to discuss in a new issue. I wonder what the consequences were if you just required |
3 participants
…rected()
andas_undirected()`