Towards 1.4.0

[torfason]

Targeted issues

As of September 2023, v1.3.1 has been released, with all items originally targeted for that.

User visible features targeted for v1.4.0 now only include #63, (config function), which has not been implemented. No target date has been set for that release. Keeping this issue open since it contains important documentation about the development process and governance of the project.

• Targeted for v1.4.0
  • [ ] #63, proposed by @torfason, based on comments by @J-Moravec

Development process

Development happens on the dev. Contributions are merged from forked repos to dev through pull requests. Stable changes are then either migrated to the main branch for wider testing before a release, or are migrated upon the next release.

There is a preference for a relatively clean linear commit history in the main branch, so it it great to keep each issue fix to 1-3 commits unless it is that much bigger. No worries though about submitting incremental pull requests, they can be rebased at the end, by either submitter or maintainer, to get back to a few logical commits with an end result for which all tests and checks pass. A recommended default commit structure is:

• Tests first in a single commit, allowing examination of how they fail before a feature/fix is implemented
• The implementation code in a second commit
• Documentation, including updates to NEWS.md and a version bump, in a third commit

The project now includes a build/build_and_release_process.R file. Contributors are kindly asked to run the code in this file prior to pushing any commits, and make sure that it (a) runs with out error and (b) does not result in unexpected modifications of project files. Among other things, the script regenerates autogenerated files, such as the *.Rd and README.md files, to correctly reflect changes in primary source files.

Governance

For anyone interested in getting involved, it might be good to give some background on the governance of this project:

The package was written by @smbache, but the package is currently maintained by @torfason. The philosophy that they share regarding import includes among other things:

• We do not have the resources to "move fast and break things" so slow and steady is the way to go
• Therefore:
  • New features should be backwards compatible unless there is an extremely compelling reason
  • New features should generally be documented as well or better than existing features
  • New features should generally have as good or better test coverage as existing features
• When it comes to choosing features both demand and supply are important
  • Demand in terms of the number of people who comment on an issue
  • Supply in terms of help with implementation

Within this philosophy, I would very much like to make any decisions on consensus, and would be most interested in hearing from people who have submitted or commented on bugs already, since they clearly care about this project in one way or another.

[torfason]

I'm planning a maintenance release of the fixes currently in main. @awong234 , @brshallo , @hutch3232 and @J-Moravec , you have made recent contributions. If you are using the package in your work flow and could update to the most recent version (1.3.0.9004) and report any regressions, that would be much appreciated. Otherwise, I plan to submit this version as 1.3.1 to CRAN by the end of the month. The 1.3.0.9004 version can be installed with:

pak::pak("rticulate/import")

or

remotes::install_github("rticulate/import")

[hutch3232]

Hi @torfason, apologies I never got back to you (funny enough, one year ago to the day). I can start testing these maintenance fixes in my workflows. I also just opened two patch PRs and I'm wondering if we could get those tested and added to this 1.3.1 maintenance release as well? #80 #81

[torfason]

That sounds great, I saw the PRs, have not had the opportunity to test them, but they look like they are fixing genuine issues. I see you've built on top of the most recent version, if you have time to do some local testing on your end, using the catch_script_err branch, I see that as a good foundation for a 1.3.1 release.

I do see that the checks are failing on github, probably just because of outdated actions. I'd be all for just throwing out the old actions and adding new versions as in:

• https://r-pkgs.org/software-development-practices.html#r-cmd-check-via-gha

We would possibly need to update for running on both PR and push, but is probably much simpler than trying to manually update each action (based on my experience with other packages). I can look into doing the action update myself as well, but would need to find time. If you do have time to look into that, and are able to do a third PR on top of your catch_script_err branch, I should be able to do my local testing and the release to CRAN without too much delay.

[hutch3232]

Thanks for the fast response! Yes I will do some testing of that branch. I haven't messed with GitHub actions before but I'm curious to learn so I can give it a try, perhaps as soon as this evening.

[hutch3232]

Wanted to update that I installed the latest branch catch_script_err locally and have been successfully using it in my real workflows the past couple of days.

[torfason]

As of now, v1.3.1 is successfully released and built on CRAN. Thanks for the help on this release, which contains the following changes

• Targeted for v1.3.1
  • [x] #68, not a code change, but worth tracking.
  • [x] #56, fixed in main (through PR #55), thanks to @awong234, but caused an unexpected regression. To fix the regression, it was necessary to change the default value of the .library parameter, as documented in #56.
  • [x] Minor cleanup of documentation.
  • [x] #81 and #82

Leaving this issue open as a central place for discussion of upcoming releases and documentation of the development process.