New milestone available: 0.11.0

[genedan]

We're close to wrapping up 0.10.0. A new milestone tag, 0.11.0, is available for new feature requests.

[henrydingliu]

can we define 1.0 first, then incrementalise around .11?

[kennethshsu]

Wow the milestone board is so messy now.

I think I've said this somewhere, but my MVP for 1.0 release are:

• New logo New logo for the package #865
• Friedland recon Reconcile data against Friedland's text used in Exam 5 #588
• API docstring API Reference Examples #704

What else do you guys want as v1.0.0?

In my mind, anything pushed out before we complete those 3 will be 0.11.0 lol

[henrydingliu]

aligned on those 3 being the 1.0 milestones.

i think governing doc deserves a 0.10.1 next week. it would also push the hamburger bug out of stable.

depending on how many detours we indulge ourselves in, i don't think we need a 0.11.0.

[kennethshsu]

i think governing doc deserves a 0.10.1 next week. it would also push the hamburger bug out of stable.

Ya we should push this out.

depending on how many detours we indulge ourselves in, i don't think we need a 0.11.0.

How about 0.11.0 to "just" implement the Governing Doc (and whatever else we got in). We actually already closed 34 tickets since 0.10.0.

[henrydingliu]

i don't think 34 scratches the number of issues between .8 and .9 and between .9 and .10.

[kennethshsu]

Probably a bad idea for me to bring up the tickets count since I think if we follow semantic versioning, the last digit is for bug fixes only. If we have ship meaningful "new" things, we should increment the MINOR number. But ya for comparison we closed 90ish tickets in 0.10.0 and that took about 3 months (we are 1 month since last release), so maybe we are on track lol

[henrydingliu]

to the average user of the package, i don't think we shipped enough new things between 0.10.0 and now.

[genedan]

What else do you guys want as v1.0.0?

I've already tagged the things I wanted with the 1.0.0 milestone. When looking at the tag it seems like many of these are still far off, even if we go full steam at them. I believe the wishlist has been fairly stable between 0.9.0 and 0.10.0. I think we should continue to chip away at the big ticket 1.0.0 items while we concurrently work on 0.11.0, once we feel like the outstanding issues are ~3 months away I think we can stop creating 0.x.0 releases.

[kennethshsu]

We actually have quite a few things tagged, even some not triaged 😱

[henrydingliu]

most of those are doable. but collectively it's too many. our priority for the repo has to be wider adoption, in order to generate greater contribution interest. from that lens, all of the internal-focused issues carry little marginal value. if we list too many issues to be on the same timeline as the 3 core ones listed above, then by definition we are deprioritizing the 3 core issues. i would be comfortable with 3 other issues (beside the 3 listed above) being on the 1.0.0 roadmap, but only 3.

the one issue i don't think we can tackle before 1.0.0 is the whole NaN issue. It's a large breaking change to existing behavior.

[kennethshsu]

Commenting at the bottom so all can see.

to the average user of the package, i don't think we shipped enough new things between 0.10.0 and now.

Not saying 0.11.0 is right or we go 0.10.1, but here's the current change log as of 9/2, following the structure in the new Governing Doc, there are definitely a few noteworthy items.

=====

Version 0.10.1

What's Changed

Changes are grouped into the standard categories below. See the Full Changelog link for the complete, unedited list of merged pull requests.

Enhancements

• Add TriangleSelector so VotingChainladder pipelines can pick a single column (e.g. paid vs incurred) per estimator by @henrydingliu in #1114
• Allow partial-triangle and non-contiguous loc/iloc assignment (numpy backend) by @henrydingliu in #1103
• Expand Triangle.drop() with index/columns/origin/development alternatives, origin-level drops, development dropping, label validation, and error options by @priyam0k in #1131, #1163, #1207
• Support cumulative on-level factors in ParallelogramOLF by @priyam0k in #1181
• Support quarterly and semiannual origin grains in ParallelogramOLF by @ppcvote in #1205
• Add dense prism_omdm/oqdq/osds/oydy sample triangles by @Abhayindia in #1233
• Add tests for triangle.py, sparse triangles, pandas helpers (drop, fillna, T), and rename a duplicate test_shift by @genedan, @henrydingliu, and @priyam0k in #1088, #1157, #1195, #1200

Bug Fixes

• Draw stochastic Benktander/BF/Cape Cod aprioris from a lognormal (not normal) so expected ultimates stay positive by @friman-howard in #1149
• Fix Triangle display crash when a Triangle is stored in a DataFrame cell by @priyam0k in #1152
• Fix valuation grain for single-diagonal triangles with year-only development dates by @kennethshsu in #1194
• Fix ParallelogramOLF daily-grain ValueError on triangles that start after a leap year by @Abhayindia in #1230
• Sparse backend: column assignment, numpy interoperability, and clearer errors for in-place values mutation by @genedan in #1164
• Remove dead backend-reset code in _prep_columns by @priyam0k in #1160
• Fix RTC table of contents and double search bars by @kennethshsu in #1150

Deprecations & Removals

• None.

Maintenance

• Add Friedland Chapter 7 notebook, Chapter 8 recreation, Chapter 9 (Bornhuetter-Ferguson, including Exhibits I–VI), and Chapter 10 (Cape Cod) by @salexanian, @kennethshsu, and @priyam0k in #1189, #1117, #1121, #1109, #1112, #1197, #1180
• Expand Triangle API examples and inherited-method docstrings (heatmap, I/O, arithmetic, cdf_/ibnr_/pipe/set_backend, broadcast_axis/copy/reindex, exp/log/sqrt/round, head/tail/sort_index, compute/pipe) by @EKtheSage in #978, #983, #984, #985, #986, #1209, #1210, #1211, #1212, #1213
• Live list_samples table, model_diagnostics demo, See Also links on core methods, Mack gallery sigma_interpolation='mack', option-name and ULT_VAL notebook fixes, and other docstring/link fixes by @SaguaroDev, @aminemanai2003, @henrydingliu, and @kennethshsu in #960, #895, #972, #1196, #1177, #1175, #1259
• Docs build with uv, automated docs on PRs, and the project governing document by @kennethshsu in #1171, #1242
• Add Ruff and pre-commit (including format, E2, B018, UP034, doctest) by @genedan, @henrydingliu, and @Abhayindia in #1198, #1204, #1225, #1217, #1214, #1243
• Fix a workflow warning and update unittest triggers by @salexanian and @henrydingliu in #1120, #1183

Dependencies

• Floor patsy>=1.0.2 and statsmodels>=0.14.6 for pandas 3 by @SaguaroDev in #974
• Remove the pandas upper bound by @genedan in #1172
• Bump setuptools (docs/dependency vulnerability), tornado, and mistune by @genedan and @dependabot in #1144, #1261, #1264

Contributors

Welcome Howard Friman (@friman-howard), Amine Manai (@aminemanai2003), @ppcvote, and Abhay Chaudhary (@Abhayindia) for making their first contributions! 🎉

Incorporated 554 commits from 11 collaborators, including returning contributors Gene Dan (@genedan), Kenneth Hsu (@kennethshsu), Henry Liu (@henrydingliu), Ethan Kang (@EKtheSage), Priyam Alok (@priyam0k), Nick Kinney (@SaguaroDev), and Shahen Alexanian (@salexanian).

Full Changelog: v0.10.0...v0.10.1

=====

[henrydingliu]

I think I am leaning towards just quietly push out a 0.10.1 and let the GH automated notes show up. I don't think it's good practice to leave out closed tickets unannounced, even though they were not documented in the right release.

But my understanding of basically what happened was that we were pushing features into experimental, and sometimes pulling features from experimental onto dev branches. When done only as exploration, this is ok, but to keep everything clean, we should've always PR from dev branches instead of (sometimes) from experimental, which we def did a few times. This messes up the ticket tracker because tickets are not "closed in a release" until the first commit that closes it show up in main, even if the feature was pulled into a dev branch and pushed to main. Anyways, this isn't a problem anymore with experimental removed.

Any objections to pushing a minor release of 0.10.1 with the above notes? We can just do this quietly with no ads/announcements.

i dont think so. the last merge from experimental was in June. https://github.com/casact/chainladder-python/pulls?q=head%3Aexperimental way before 0.10.0.

[kennethshsu]

@henrydingliu I feel like you know something that I don't lol.

What exactly is causing this and how do we fix this? If it's not the experimental branch then what is it?

[henrydingliu]

i just knew it wasn't experimental. if you recall, before we deleted experimental, we didn't do that one last merge. instead, we just merged in the incremental changes separately.

[kennethshsu]

But isn't that exactly the issue? Is that sometimes we PR from experimental to main and some times from dev branch to main? So all the tags are mixed up?

I can do a bit more research and reading on how those notes are generated. I thought they are pinned to commits? I also don't have a very good foundation of git, just learn as I go🫢

[henrydingliu]

i'm just saying we stopped using experimental about a month before 0.10.0. we can go back and check if 0.10.0 release note contained any spillover from 0.9.0

[genedan]

One thing on my wishlist is to have something worth of a "Show HN" post on HackerNews. I guess I don't know whether anyone on that site would be interested, but I do fantasize about us getting traction from there.

[henrydingliu]

i think we don't have a lot of runway in terms of engineering achievement given the domain. but there's plenty of macro socioeconomic shock-jocking we can do to trend on HN. for example, we can set this package loose on some aggregate health UIE data and generate a headline like "my python package reveals $4.6B in unrealized extra profit by healthcare insurers".