v6 Release

This issue serves as a place to discuss what to include in this version, since major version bumps allow us to make breaking changes we think are necessary or worth it.

The wishlist keeps track of the items to include, but items may be added or removed at any time.

As changes are completed, they are added to https://github.com/angularsen/UnitsNet/wiki/Upgrading-from-5.x-to-6.x

Changes

Remove BtuPerSquareFootDegreeFahrenheit Remove obsolete units #1372
Fix plural form of Speed.MeterPerMinute
Rename/fix calorie/btu units to specify their definition as International Steam Table (IT) or Thermochemical (th), see https://github.com/angularsen/UnitsNet/pull/1196/files#r1105112205
Consistent imperial/UK/US unit namings v6 Release #1200 (comment)
UnitAbbreviationsCache.ctor() should create empty cache, not load default abbreviations 💥Change UnitAbbreviationsCache ctor to not load defaults #1476
UnitParser.ctor(UnitAbbreviationsCache) should not fallback to built-in units if given null 💥Change UnitParser ctor to require unit abbreviations cache #1477
Rename AbsorbedDoseOfIonizingRadiation to RadiationAbsorbedDose Add radiation equivalent dose #1352 (comment)
Review all [Obsolete] in code and add to this list
- Remove obsolete Equals overloads 🐛ComparisonType ignored in obsolete Equals method #1396 (comment)
- ~~Remove static Default getters pointing to UnitsNetSetup.Default~~ 🔥Remove static Default getters, obsoleted by UnitsNetSetup #1475 reverted by Revert "🔥Remove static Default getters, obsoleted by UnitsNetSetup" #1480
Fix typo in TonneSquareMilimeter, missing l
Fix typo in VolumeConcentration.LitersPerMililiter, missing l VolumeConcentration: fix typo in LitersPerMililiter (missing 'l') #1497
Remove TorquePerLength: dimensionless, domain specific, conflicts with Force = Torque / Length Removing TorquePerLength #1458
Rename ThermalResistance to ThermalInsulance: enables future conversions between thermal conductivity, resistivity if added Rename ThermalResistance to ThermalInsulance #1460
Change Angle base unit from Degree to Radian
Fix typo KiloNewton => Kilonewton in SpecificFuelConsumption.json
UnitParser: fix the nullability of the Parse / TryParse overloads #1445
v6-Electric #1467
💥Remove obsolete electric quantities #1482
PressureUnit: remove the MeterOfElevation and FootOfElevation #1531
Remove IConvertible from IQuantity Removing the IConvertible interface and fixing the JsonNet converters handling for nulls #1550
Update wiki regarding IQuantity and sample quantity Length Per Angle Unit (e.g. mm/rev, m/degree) #1519 (comment)
Consolidate UnitsNetSetup.Default.UnitConverter and each quantity's DefaultConversionFunctions, these can become inconsistent when adding custom conversion functions at runtime. Consider making DefaultConversionFunctions internal, not public.
Moved IQuantity methods to extension methods with Untyped suffix, e.g. ToUnit() becomes ToUnitUntyped() to improve intellisense from strongly typed extension methods Replace As(UnitSystem) and ToUnit(UnitSystem) with extension methods #1600
Remove .NET nanoFramework support, now maintained and published separately by the nanoFramework team at nanoframework/nanoFramework.UnitsNet Remove .NET nanoFramework support #1676
Fix ambiguous prefixed cubic volume and specific-volume units: reserve hm³/km³ for true cubic hectometer/kilometer units, rename count-style cubic foot/meter units, and fix mm³/kg Convertion from m³ to hm³ always 0 #1617 Conversion from m³/kg to mm³/kg is wrong #1645 Fix ambiguous prefixed cubic units #1700
Standardize quantity formatting on .NET numeric format strings: remove proprietary A, S, U, V, and Q formats and add StringSyntax metadata Standardize quantity formatting on .NET numeric formats #1721

Fixed

UnitsNetBaseJsonConverter fails for custom quantities that are declared nullable #1465

Add System.Text.Json support #966

Decide on a naming and abbreviation convention for imperial/UK units and US units; like gallon, ounces, cup etc.

It is a bit of a mess right now:

LINQPad sample

void ListUnits(string withPartialName)
{
    Quantity.Infos
        .SelectMany(i => i.UnitInfos
            .Where(n => n.Name.Contains(withPartialName))
            .Select(u => new 
            { 
                u.Name, 
                Abbrev = UnitAbbreviationsCache.Default.GetDefaultAbbreviation(u.Value.GetType(), Convert.ToInt32(u.Value)) 
            }))
        .Dump(withPartialName);
}

ListUnits("Uk");
ListUnits("Imperial");
ListUnits("Us");

I personally like "UK", since it is shorter and better matches "US".
Wolfram also uses US gallon and UK gallon.

Some conventions for imperial gallons:
https://en.wikipedia.org/wiki/Gallon#:~:text=the%20imperial%20gallon%20(imp%20gal,American%20and%20Caribbean%20countries%3B%20and

Today the abbreviation convention is gal (U.S.) and gal (imp.).
Depending on landing on UK or imperial naming, we could go with one of these pairs:

US gal and UK gal
US gal and imp gal
gal (US) and gal (UK)

We can support multiple of these plus the old ones, but the primary form should be standardized across the different units.

Do not throw ArgumentException on NaN, Inf+ or Inf- or give a way to configure the behavior globally.

Context:
#1268 (comment)

I think UnitsNet should be more extensible. Perhaps there could be a base package, but separate NuGet packages for US measurements, Imperial, UK, etc. Alternatively, customizable abbreviations could be a solution. I would never expect me or my users to see "gal (US)" instead of "gal". This would also help the debate here.

UPDATE:

Custom abbreviations already exist: UnitAbbreviationsCache.Default.MapUnitToDefaultAbbreviation(HowMuchUnit.Some, "sm");

I think UnitsNet should be more extensible.

Conceptually, I agree.

Customizable abbreviations is already supported as you found, and we support custom quantities and units with some limited functionality: https://github.com/angularsen/UnitsNet/wiki/Extending-with-Custom-Units

Splitting up in packages is not so easy though. Things like Torque = Force * Length becomes problematic when types exist in different packages and they can't have circular dependencies. Imperial is even worse, splitting some units of a quantity to different packages. The main problem is static typing, which is also one of the main features of UnitsNet.

One benefit of splitting up in packages is smaller binary size to only bring in what you need.
Some prototyping here: #1181

I was requested to give a list of units with the wrong plural form (see #1330 )

I checked the .json-file with the speed units and only MetersPerMinute has a wrong plural form, all other Speed units seem to have the correct plural form.

Fix typo: Celcius -> Celsius (#1347)

Fix more unit names (#1351)

@Markussp256

@Markussp256

I was requested to give a list of units with the wrong plural form (see #1330 )

I checked the .json-file with the speed units and only MetersPerMinute has a wrong plural form, all other Speed units seem to have the correct plural form.

Some more fixes were made recently in
#1351

Generate operators from unit relations defined in JSON (#1329)

💥🐛Change DataMember ordering to 1-indexed (#1360)

💥🐛Change DataMember ordering to 1-indexed (#1360) (#1363)

Remove obsolete units (#1372)

💥Change UnitParser ctor to require unit abbreviations cache

💥Change UnitParser ctor to require unit abbreviations cache (#1477)

@lipchev

Big fat release on the way out, merged in changes from master.
Previous release was Aug 23.

Release UnitsNet/6.0.0-pre013 · angularsen/UnitsNet

@lipchev

Fix typo in MassMomentOfInertia.TonneSquareMilimeter (#1490)

Rename SpecificFuelConsumption.GramPerKiloNewtonSecond to GramPerKilo…

With IQuantity implementing IParsable would it also be desirable to add support for IUtf8SpanParsable?

With IQuantity implementing IParsable would it also be desirable to add support for IUtf8SpanParsable?

In the current implementation the QuantityParser, with its regex and all, is the worst performing class of the whole library. There are also potential problems that need fixing regarding the fall-back culture (see #1443 ), but given how slow we've been moving with the PR reviews lately, and how many of those I've got in the pipeline, I decided to leave it for another day.

That said, if you want to take a stab at it, I'll have a look- but please have a look at the direction I took in #1507, I think that would be a necessary first step towards a more performant implementation.

In the current implementation the QuantityParser, with its regex and all, is the worst performing class of the whole library. There are also potential problems that need fixing regarding the fall-back culture (see #1443 ), but given how slow we've been moving with the PR reviews lately, and how many of those I've got in the pipeline, I decided to leave it for another day.

That said, if you want to take a stab at it, I'll have a look- but please have a look at the direction I took in #1507, I think that would be a necessary first step towards a more performant implementation.

Ah, I probably should of taken a closer look at how the QuantityParser was implemented before asking as I was hoping it would be a easier lift since I mostly wanted it to move/unify some generic parsing logic to all use IUtf8SpanParsable in my code base.

Still I'll run some profiling on my side of things and see if I can justify some time to put some work into optimizing the QuantityParser.

Update wiki regarding IQuantity and sample quantity #1519 (comment)

I've been reading through the custom units page and the sample quantity does not conform to the up-to-date IQuantity interface.

QuantityType no longer exists,

QuantityInfo has had some breaking changes, relating to QuantityType and UnitInfo,

QuantityValue Value { get; } had replaced double Value { get; },

and bool Equals(IQuantity? other, IQuantity tolerance); has been added to the interface.

When issue?

When ready.
Mainly waiting on #1544 and then some time to collect feedback.

A prerelease nuget is out so you can go ahead and use v6 now.

.NET nanoFramework support removed in v6

As of #1676 (closes #1647), the in-repo .NET nanoFramework projects, code generation, build steps and CI/pipeline tasks have been removed.

nanoFramework support is now maintained and published by the nanoFramework team in their own repository, with their own NuGet packages:

Repository: https://github.com/nanoframework/nanoFramework.UnitsNet
NuGet: one package per quantity, e.g. nanoFramework.UnitsNet.Length, nanoFramework.UnitsNet.Mass, ... (search nanoFramework.UnitsNet on NuGet).

Migration for nanoFramework users: replace the old UnitsNet.nanoFramework.* packages with the new nanoFramework.UnitsNet.* packages. The previous packages published from this repo are deprecated.

Tracked in #1721 as a behavioral breaking change for v6.

This consolidates the quantity-format cleanup:

A/An duplicates the explicit generated GetAbbreviation() APIs and UnitAbbreviationsCache, including localized and runtime-configured abbreviations.
Remove unnecessary format strings #797 intended to remove S, but commit 721287d removed only its documentation and tests; the v5 formatter implementation still supports it. This PR completes that cleanup. The QuantityFormatter defaults to the "G" format #1450 discussion also questioned retaining a formatter that can hide precision. Callers can state their intent with standard/custom numeric formats such as G3, F2, N2, E2, or 0.##.
U, V, and Q were already removed during the v6 redesign and are now documented together with A and S as one migration.

Adding StringSyntaxAttribute.NumericFormat to the public formatting surfaces makes the supported contract explicit and enables IDE format-string assistance. The v6 upgrade guide and string-formatting documentation contain the complete replacement table.

Standardize quantity formatting on .NET numeric formats (#1721)

Sunbelt Computer Software

PL/B Language Development and Support

Navigation Menu

v6 Release #1200

Changes

Fixed

30 remaining items

.NET nanoFramework support removed in v6

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Sunbelt Computer Software

PL/B Language Development and Support

v6 Release #1200

Description

Changes

Fixed

Activity

maxreb commented on Mar 21, 2023

angularsen commented on Apr 1, 2023

ebfortin commented on Jun 24, 2023

MisinformedDNA commented on Sep 12, 2023

angularsen commented on Sep 16, 2023

Markussp256 commented on Nov 29, 2023

angularsen commented on Jan 6, 2024

30 remaining items

angularsen commented on Dec 29, 2024

Anthonywolfe commented on Apr 1, 2025

lipchev commented on Apr 2, 2025

Anthonywolfe commented on Apr 2, 2025

angularsen commented on Apr 12, 2025

MohMehrnia commented on Nov 26, 2025

angularsen commented on Dec 6, 2025

angularsen commented on Jun 11, 2026

.NET nanoFramework support removed in v6

angularsen commented on Aug 1, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions