Time for a new release (1.3.0)?

[torfason]

It's now been around 18 months since the last release of import and I've been thinking about whether it is getting to be time for a new one?

I am opening this issue for any interested parties to chime in, with suggestions on which issues would be most important to get into such a release (and of course for anyone who would like to offer assistance). Here is a first stab at a list (to be updated):

• [x] An annoying release blocker, #60, now fixed in dev

• [x] Some of the issues are genuine bugs. Even if none of them seems to impact too many use cases individually, it would be very nice to fix them. (some of them have either PRs or clear approaches to fixing).

  • [x] #57, now fixed in dev(fixed through PR #62), thanks to @brshallo
  • [x] #59, fixed by @awong234, in preparation for merging to dev

• [x] Others are enhancements. Getting them into a release depends both on whether there is interest in implementing, and on whether we can find a way to do it without breaking existing usage.

  • [x] #54, was implemented by @hutch3232
  • [x] #53, was implemented by @hutch3232 and tested by @brshallo?
  • [x] #58, initial (experimental) implementation by @J-Moravec, just needs a bit of cleanup and documentation.

    • 16 is a duplicate of sorts

• [ ] Postponed for a later release

  • [ ] #56, fixed in dev (through PR #55), thanks to @awong234, but caused an unexpected regression. Fix probably identified, but aim is to release this separately.
  • [ ] #63, proposed by myself, based on comments including by @J-Moravec on other issues. Might be nice to have?

Dev process

Update: Staging area has been moved to the main repo

dev refers to rticulate/import@dev. This branch will be the staging area, with a final omnibus PR to rticulate/import@master.

There is a preference for a relatively clean linear commit history in the rticulate@master 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, I can rebase them (or people can rebase themselves) 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 in a third commit

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 and I consider him to be the "benevolent dictator" of this project. I became involved around the last release, and because of his time constraints he assigned me as the lead maintainer for the purposes of CRAN submissions. The philosophy that I think the two of us 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.

The floor is open :-)

[torfason]

I actually think the issues marked as "genuine bugs" above might warrant a 1.2.1, and then the other enhancements could be added in a 1.3.0 release (which could happen soon after).

[torfason]

Update: I've moved the staging area into the main repo, which should simplify the preparation of PRs, it would now be best if contributed PRs are based on (and made to) the following branch.

• rticulate/import@dev

[torfason]

All outstanding bugs and some enhancements are now resolved in dev.

As the number of outstanding issues gets smaller we will need to decide whether to (a) hold off on releasing for a couple more weeks in order to resolve outstanding issues (#53, #58, and possibly #63), or (b) do a 1.2.1 release now, with an eye on following it up with a 1.3.0 (possibly relatively soon) with those added features. Thoughts?

[brshallo]

Maybe doesn't make logical sense, but (selfishly) I am a fan of:

(b) do a 1.2.1 release now, with an eye on following it up with a 1.3.0 (possibly relatively soon) with those added features.

but also with #53 included.

As that is the easiest path for me to put funspotr on CRAN (which I'd like to do ahead of talk on it at Rstudio Conf in July).

[torfason]

@brshallo, I had noticed that, and yes, I'm all set on submitting to CRAN, based on the dev branch (which includes #53) in time for that. I was thinking we had a few weeks left of slack, but with a hard deadline by the end of May, to submit whatever we can get into dev.

What is left is basically:

• A bit of cleanup and documentation of S3 imports, #58, which I think @J-Moravec is looking into.
• And a regression that I recently discovered (as I was making preparations for the CRAN release process), in #56, which @awong234 is looking into.

[torfason]

All features/fixes targeted for v1.3.0 are now in dev and master has been forwarded to match dev, and the version bumped to correspond to that. All checks required for a CRAN release see to be passing, and the plan is to submit to CRAN after the weekend, unless any unknown issues are uncovered until then. In the meantime, it would be much appreciated if the people involved in the new features/fixes could check out this could install and try out the most recent version from GitHub, for example using:

pak::pak("rticulate/import")

(remotes::install_github("rticulate/import") or devtools::install_github("rticulate/import") should give the same result)

Thanks to everyone for their contributions!

[torfason]

I'm happy to say that v1.3.0 is now live on CRAN and the binaries are popping up one by one. 🙂

This release has truly been a team effort, with contributions from @awong234, @brshallo, @hutch3232, and @J-Moravec. These have been both in the form of tests, code and documentation, but also in some deep dives into the inner functionality of import – something that has been important both for added confidence about this release, and to look forward to next steps. With a package that deals with NSE, environments, the library path, and now S3, having several pairs of eyes on how these things interact is crucial to not end up in regression hell. Thanks everyone!