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

=====

[ppcvote]

Following up on the stray-branch idea. I think it is #1121 ("Friedland Recreation Chapter 8", #588_chapter8 into main, merged 2026-08-11). Commands at the bottom so you can check rather than take my word for it.

Of its 315 commits, 98 have author dates from 2026-05-08 to 2026-05-11, before the v0.9.2 tag. Its merge commit 6ca44ed is absent from v0.9.2...v0.10.0 and present in v0.10.0...main, so that work reached main 18 days after v0.10.0 was tagged.

Those 98 appear to be all of it. Every commit in v0.10.0...main whose author date precedes the v0.9.2 tag is one of #1121's, so I did not find a second stale path.

One trap if you go checking: pulls/1121/commits caps at 250, and for this PR the 65 it drops are the 65 oldest, which understates the count to 33. compare/{base}...{head} returns all 315.

On duplication specifically: no commit appears in both ranges. v0.9.2...v0.10.0 is 524 commits, v0.10.0...main is 690, and the intersection of their SHA sets is empty. That would not catch the same diff landing twice under two SHAs after a cherry-pick, which I did not check for.

Relevant to your table: 6ca44ed has two parents, so #1121 went in as a merge commit rather than a squash, and all 315 of those commits landed individually in main.

gh api --paginate "repos/casact/chainladder-python/compare/v0.9.2...v0.10.0?per_page=250" --jq '.commits[].sha' | sort > a
gh api --paginate "repos/casact/chainladder-python/compare/v0.10.0...main?per_page=250"  --jq '.commits[].sha' | sort > b
comm -12 a b | wc -l    # 0

BASE=$(gh api repos/casact/chainladder-python/pulls/1121 --jq .base.sha)
HEAD=$(gh api repos/casact/chainladder-python/pulls/1121 --jq .head.sha)
gh api --paginate "repos/casact/chainladder-python/compare/$BASE...$HEAD?per_page=100" \
  --jq '.commits[].commit.author.date' | awk '$0 < "2026-05-11T18:36:13Z"' | wc -l    # 98

[henrydingliu]

take pandas for example. there have been roughly 40K PRs and 40K commits.

we have about 600 PRs and 3K commits.

[kennethshsu]

Thanks @henrydingliu I think it makes sense to not do Merge Commit, it was fine when the project was small, but it looks super messy now. I am also someone that likes to make lots of small commits just because I am paranoid of AI change stuff and having trouble undoing, so agreed we should stop Merge Commit.

I think Rebase is the same thing, doesn't fix the messiness, but other reason to keep this one?

We change this setting at the repo level. So If we are all aligned on Squash we should just document this in the Governing Doc and change the setting.

[henrydingliu]

rebasing is only allowed when the two commit history (main and PR branch) are compatible. on a PR with only a couple of commits, rebasing and squash essentially ends up with the same outcome. rebasing is easier because you don't have to rewrite the commit description.

this is a screenshot of gene's PR. when i try to squash and merge, i have to reenter the commit description. my typical practice is to just copy over the PR summary into the squash commit.

a rebase doesn't require any additional description, as the existing commits just get harmonized into the main branch.

[kennethshsu]

Let me convert this into a ticket.

[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".

[henrydingliu]

starting a new comment after 0.10.1.

what's currently slated for 0.11.0 at this point looks to be mostly chores + deprecation and styler. looks very manageable. given styler and deprecation are already in a PR. i'm leaning towards a 0.10.2 instead in about a month's time, and skip 0.11.0

i think we are all aligned to @kennethshsu's proposal for minimum enhancements by 1.0.0. looking through the remainder of the 1.0.0 issues. i see these 3 major pieces.

A. changing NaN behaviour
B. dims standardization
C. option clean-up

I don't think A is doable before we deprecate sparse, and that's difficult to justify before 1.0.0. B and C are very achievable, especially when priyam gets reinstated.

[kennethshsu]

Semantic versioning says the last digit is for bug fixes only though. Any meaningful new features implemented should bump the second number, the "minor".

Aligned with the other goals.

[henrydingliu]

okay. so the next release is still 0.11.0. i'm good with that.

[genedan]

I just tagged a bunch of untagged issues (I was holding off until we got 0.11.0 decided upon). I closed some issues too that weren't followed up upon from the authors. Feel free to do another sweep.

[genedan]

Yeah, big things would be:

• Typing: I almost have core done but pretty much the rest of the library needs to be typed. I think the work can roughly be split by folder without too much interference if one person each handles a folder
• knocking out the rtest files Clean up rtest files #1087
• Pytest warning elimination [TEST] Reduce pytest warnings #840 : pretty much all of it
• Deprecation stuff [FEAT] Add general deprecation tools #1318 : updating the contributing guide on how to use the 3 functions and writing a script to check for them upon release

[henrydingliu]

okay. i've started on #840. it's gonna be a mix of test changes but also some code changes here and there. #1408 is the first in the series. please take a look when you get a chance.

the deprecation stuff is not worth our time beyond what's already landed imo. we can manually keep a list of deprecated features, rather than adding another piece of code. i also expect only experienced contributors, who can already pick up the use pattern from existing examples, to take on deprecation. so a guide is low value.

[genedan]

@kennethshsu do you actually want the two remaining items in #1318? It's mostly to aid you in the release process, but if this is a case of features that nobody asked for, we can close it.

[kennethshsu]

I don't care that much about #1397, so I think we can close that without implementing it.

I think #1398 is important (and I can take it).

[kennethshsu]

#1398 is not quite ready though, we still need to finalize what goes inside the deprecation function first.

[genedan]

Do you guys think 1.0.0 is achievable after 0.11.0? I don't want to add any more issues (for myself) for 0.11.0, unless they are related to current parent level issues. I think we should set a soft target for a November 1 release, shortly after Python 3.15 comes out.

I think if we can knock out deprecating the dims, we can move towards wrapping up the NaNs problem, which I think is the main blocker for 1.0.0?

I could start tagging new issues with 1.0.0, but if you don't think we're ready I could open up a 0.12.0 tag.

[kennethshsu]

I'm aligned with the terminology, so yes we basically have something like this:

Now ---> [W]arning issued ---> Function/Parameter [D]eprecated/removed ---> Future

The current "deprecation function" is really to emit a message in "W", it says

_____ is deprecated and will be renamed to _____ in version [D], and by version [D], the function/parameter no longer exists.

My preference would be:

_____ is deprecated since version [W] and will be renamed to _____, [W] is the date that we release warning, and when version "D" comes, both that the warning is removed and the function/parameter will be deprecated (no longer works)

While it's best to have both dates like:

Since version [W], _____ is deprecated and will be renamed to _____ in version D, similar to the example you linked. It does mean we need to commit to both [W] (of course we can), and [D] (we may or may not know for sure, what if at the next major release we aren't ready to fully deprecate this?)

Here is another example using just my proposal.

By the way, this is just my proposal, which really focuses on what is "good enough" for the users and the least amount of work for the maintainers.

There was a comment/feedback about the passive aggressiveness tone of the message. Is it a wording issue? Or is it that we simply don't like the proposal and prefer the first way?

[priyam0k]

Do you guys think 1.0.0 is achievable after 0.11.0? ... I think if we can knock out deprecating the dims, we can move towards wrapping up the NaNs problem, which I think is the main blocker for 1.0.0?

The #181 issue is definitely real for incrementals, but untangling it from sparse is a big architectural lift.

If the upcoming release in November is 0.11.0, we could plan for a 0.12.0 after that to tackle the NaN/sparse refactor and any other major architectural changes. That way, we take care of the heavy structural work across 0.11 and 0.12, and 1.0.0 can be our truly stable, long-term release without needing another big overhaul right after. Open to thoughts on this.

i think at this point, new deprecation should survive 1.0.0. otherwise it feels like violating the spirit of the major/minor release cycle.

Deprecations introduced in 0.11 should still work (with a warning) in 1.0.0 so we don't break existing user workflows on upgrade.

The current "deprecation function" is really to emit a message in "W" ... My preference would be: _____ is deprecated since version [W] and will be renamed to _____

Saying "will be renamed in 0.11.0" when the warning is first shipping in 0.11.0 is confusing since the old name still works. Stating since="0.11.0" with an optional removal parameter gives us flexibility without locking us into a specific release.

I think #1398 is important (and I can take it).

+1 on taking #1398 for the Governing Doc.

On a personal note, i feel things have been moving quite fast with AI productivity. I just want to make sure I really understand every piece of the codebase and the changes going in.

[kennethshsu]

Saying "will be renamed in 0.11.0" when the warning is first shipping in 0.11.0 is confusing since the old name still works. Stating since="0.11.0" with an optional removal parameter gives us flexibility without locking us into a specific release.

This is not what I'm saying though... I'm saying the warning says something like, "feature X is being deprecated since version W (NOT D), use feature Y instead."

[genedan]

I read over PDEP-17. Turns out they aren't that strict with semver. There are plenty of examples of breaking changes between minor versions, and each deprecation is a judgment call.

For us:

• Things like renaming PTF to ptf? Technically a breaking change, but if you can't figure that one out I don't know what to tell you (IDEs do autocomplete these days...) -> minor version deprecation OK
• Returning a multiindex instead of a DataFrame when getting the index axis? Pretty big change -> needs major version update

[henrydingliu]

i don't think we have any real disconnect on the mental model that impactful things gets a longer runway. the only question we need to align on is, does 1.0.0 ship with sparse?

• if it does, NaN stays. 1.0.0 can go after 0.11.0. nothing gets removed.
• if it doesn't, we probably need 0.17.0 to fix NaN before 1.0.0. anything can be removed prior to 1.0.0 in two years.

two side issues

• i personally don't think [DOCS] Write deprecation guide in Governing Doc #1398 would do anything. there's never going to be a deprecation that we would trust a contributor to just read a guide and figure out. A useful deprecation guide has just one line. raise an issue and discuss with maintainers. anything more than that is busyware.

• @kennethshsu this entire thread makes it self-evident that we should talk things out prior to even the warning going up, instead of just saying "soon" in the deprecation notice. it's not an easy conversation. so the most responsible thing to do is to actually have it ASAP. that was gene's original point about making it mandatory to list the version for removal. if you really think we should just say soon, then we stop this convo right now. sparse deprecation goes up. NaN deprecation goes up. they all just say soon. future us will figure it out, why not