The package line

master develops the 3.2 package line as of 2026-08-24. All ten packages — HiGeom, HiLicense, HiDisp, Hi.WinForm, Hi.WpfPlus, HiCbtr, HiMech, HiUniNc, HiNc, HiNc-Resource — moved to 3.2 together and restarted their build counters.

Four consequences worth stating plainly:

• A 3.2 build number starts low, and the two counters are not comparable. The gap between the last 3.1 number a feed served and the first 3.2 one is expected rather than a missing upload.
• The ten counters are independent. They did not restart at a common value and they do not advance together: a package's counter moves only when that package is rebuilt, so the ten numbers spread apart and stay spread. Where two of them happen to agree it is coincidence, not a shared set number. A set is named by its HiNc package version — the top of the library stack, and the number the application shows as its own version mark — while the nine packages under it carry their own builds.
• The published packages reference one another with a floating 3.2.*, so restoring HiNc pulls the newest 3.2 build of each dependency rather than a fixed, reproducible set. A build that has to be reproducible pins each package explicitly.
• The 3.1 line is closed at the 3.1.175 set and is serviced only as patches on that set. A package on the service line keeps the 3.1 build it was frozen at and gains a fourth segment of its own, so the set is quoted as 3.1.175.<patch> after its HiNc package while the packages beneath it publish under their own frozen builds — looking on the feed for every package at 3.1.175.x finds only HiNc. A reference left on that set receives correctness fixes for it and none of the capability on this page. The 3.1 builds above 3.1.175 were never published as a release set — which is why 3.2.7 is the first numbered 3.2 drop and absorbs what a caller moving off 3.1.175 has not seen as a published set. Later 3.2 builds are incremental, the same way 3.1.175 / 3.1.173 / … were.