Strategy to work toward a v0.1.0 release

[dgkf]

Following on https://github.com/pharmaverse/admiral/issues/1315, I think it would make sense to aim for a release of features that are stable. Given that the package is currently a mix of stable features and experiments, any foreseeable release would need to differentiate these features.

Just to give a brief overview of the breakdown of stability

stable	partial_time class, iso8601 parsing, field accessors, field assignment, imputation, comparison operators
experimental	timespan class, partial_difftime class, arithmetic operators (primarily -)

To try to build toward an initial release, I'd like to decide on a direction for the package. Some options that come to mind, either

• Relegate developing features to a dev branch, and slowly migrate their features into releases as they mature
• Release with experimental features, but tag as lifecycle::experimental and perhaps issue warnings when using developing features

The former is more controlled, where the latter would make it easier to get feedback on developing concepts.

[dgkf]

@thomas-neitmann

Can you highlight which pharmaverse packages are planning to leverage parttime so that I can review the feature set that you need in a v1? This package started as an exploratory project and has quite a wide, but half-baked feature set. I think you all are only using the most polished parts of it, but I want to formalize the lifecycle of some of the exploratory stuff before a v1 and want to make sure everything you're using is production-ready.

I can do the work of combing through what parts of the namespace you import, but need to be pointed in the right direction. Right now I'm not 100% sure I know all the places where you're planning to use it just to start to look.

[thomas-neitmann]

@bundfussr @bms63 Please provide your input here.

[bundfussr]

I think from the admiral family of packages only admiral core will use parttime. The main feature we need is as.parttime(). The experimental features we do not need for the first release (and most likely we will not use them in the future).

[bms63]

as.partime is the only one I thought we would need. I was under the impression that this would replace a lot of the code we currently have in here - https://github.com/pharmaverse/admiral/blob/main/R/derive_date_vars.R

I'm not sure of other use cases, but we can be mindful.

We plan to release v9 and v10 of admiral according to this schedule.
https://github.com/pharmaverse/admiral#release-schedule

Maybe we could integrating partime for v10?

[dgkf]

Excellent - thanks both for the feedback.

The as.parttime interface is definitely mature. I also see some impute functions that can probably leverage parttime if you choose to go that route. If you do any datetime arithmetic, that might also be impacted since methods are exported for base operators operating on parttime objects.

The various operators are still a bit in flux as we flesh out partial difftimes and timespans - which would be the result of subtracting partial times. As long as you're just parsing or imputing you're fine.

[dgkf]

Now up on CRAN :tada:

[bms63]

Congrats!!