When to release 1.0.0?

[facelessuser]

Currently, we are on a 0.X.Y release. This can be considered a prerelease, but it is public. I'm trying to decide what if anything needs to happen before we call it 1.0.0.

For the most part, the API is finalized. Could it change? Maybe. I'm not sure yet, but overall, most of the bugs have been shaken out.

Overall, I don't think new features should hold up a 1.0 release, they can always be added later.

• Is there anything else we want to do before 1.0.0? Are there any areas we still aren't quite happy with things?
• Should we wait to see if they (CSSWG) formally add XYZ D65?
• Should we wait to see if they (CSSWG) formally add Oklab?
• Should we give more time to see how much they shake up the syntax? Some browsers are implementing some of the color changes, but there is no guarantee when they are going to be done changing things.
• Should we be concerned about how none may get handled before 1.0?
• Should Do we force hue to be undefined when white or black (think lightness 0% or 100%)? #81 hold us up? Do we need to implement this exactly like CSS?
• Should we be concerned about color(space X X X / X) syntax and how we use it for all colors? It is technically only speced for rectangular spaces, but 🤷🏻. [css-color] Support all existing (non-legacy?) formats in color()? w3c/csswg-drafts#6741
• Wait for resolution on percentages. [css-color-4] L as <percentage> in lab() and oklab() w3c/csswg-drafts#6761
• Document creating plugins. Document adding new color spaces, ∆E methods, and gamut mapping methods #99
• Provide a lighter variant default Color object that only provides the current, accepted CSS colors? Users would need to subclass and register additional, provided colors if desired. Limit default colors and plugins to just CSS colors? #101
• Gamut mapping algorithm is up in the air right now. Lch isn't perfect, but the CSS recommended one isn't either. The question is which one is more egregious. Gamut Mapping Lch vs Oklch #118
• Percent handling is currently being decided upon, and while it seems to have been decided for non color() syntax, things are still to be decided for the color() syntax, assuming they implement it in CSS. Percent handling in Lab, Lch, Oklab, Oklch, etc. #116

[facelessuser]

I think we are going to cut a 0.1.0 prerelease (no alpha) and move forward with that for now. I'm not sure when a 1.0 will occur, but we will at least move from alpha.

[facelessuser]

Updated the issue pertaining to when we are to release 1.0.

[facelessuser]

XYZ has been decided. xyz will now refer to D65 and identifiers xyz-d65 and xyz-d50 are also now official.

It also seems that none has been decided.

I say "decided", but the CSS spec is predictable. I can't wait until CSS 4 becomes stable.

[facelessuser]

There is now an open issue for potentially supporting all colors via color() over at the CSSWG. Assuming the question is addressed and answered some time soon-ish, it seems it would make sense to wait for this resolution before releasing 1.0.

Additionally, there seem to be some discussions on how percentages should be handled now that some color spaces have ranges for lightness between 0 - 100 and some 0 - 1. There is talk about potentially supporting percentages based on the context of the channel, maybe relative to some large Cartesian space.

[facelessuser]

XYZ was renamed to xyz-d65. This is the new name of the Color space object, this doesn't affect CSS syntax as xyz is still an alias for xyz-d65, but it does affect any operation where the color space name is used directly.

[facelessuser]

I've created milestone 1.0.0 to track this work. This doesn't mean these issues won't be available in a pre-release earlier, but that these need a resolution prior to 1.0.0.

[facelessuser]

We've spent the last month or so doing a lot of optimizations. We've been able to squeeze out quite a bit of speed considering we don't use numpy. We'll never be blazing fast, but we were very pleased with our outcome.

We are really down to only four things we'd like to have identified before a 1.0 release:

1. Are they going to formalize the color() syntax for any color in CSS?
2. Is the current draft of percent handling for oklab, lab, oklch, and lch how its actually going to be?
3. Are we really sticking with Oklch as the gamut mapping color space in CSS, despite its issues in the teal/blue regions? That's not saying LCH doesn't have its own issues in the blue region, they are just less abrupt and weird.
4. Are we going to reduce the stock colors to just what's in CSS or kick the other color spaces to coloraide-extras?

At this point, I can't imagine much more refactoring.

[facelessuser]

If push comes to shove, the following items could be punted to a later date for resolution:

• Gamut mapping Lch\Oklch. Both are currently available, the only question is which should be the default, and if CSS will tweak their algorithm. I'm currently thinking we may just provide our enhanced, smoother version of the CSS Oklch version and drop the rigid one that can give choppy colors. Regardless, this is not a blocker as all functionality is there and swappable.
• Reducing default, shipped colors could also be punted. Worse case is that some people will have to grab the "Extras" package if we move something they used to use, but this is not something that has to hold us up if we don't have a decision right away. Any change though would be on a major release boundary.

The two I feel I really want answers on though are:

• Percent handling. I'm really curious to see if others adopt this or have issues with them limiting percentage ranges to display P3.
• Will CSS use color() format for all colors? If so, what will that look like, and will it break our current implementation?

[facelessuser]

At some point, I may just have to break down and release. CSS moves so sloooow.

[facelessuser]

We may or may not rename some things, but at this point, I think the last item we need to fully consider before a 1.0 release, is how we want to handle all the color spaces we've implemented. Once we are done with the current changes, we'll update coloraide-extras to be compatible. Then we need to decide what we are going to do. I don't think we should have all the color spaces loaded by default. For every additional color space added, you have to carry around the reference to do them, and search through the references when converting strings to colors or converting, and it adds a little bit of overhead. So keeping it lean-ish out of the box is probably preferable.

Do we move the spaces to coloraide-extras? Do we just unregister them and ship with coloraide? Do we move coloraide-extras into coloraide and leave those spaces unregistered? I think I'm leaning towards just moving them to coloraide-extras...

[facelessuser]

I think we'll prepare an alpha release for 1.0. It doesn't yet have the default registered color spaces reduced yet.

We'll get coloraide-extra working with the new alpha and release an alpha there, and then we'll start considering what to do with the more frivolous color spaces that arent considered essential.

[facelessuser]

There may be a few more breaking changes that sneak in during the alpha stage. I'm considering renaming some functions, but I'm not sure yet.

[facelessuser]

We've addressed everything we wanted to. I think we'll actually be releasing a beta.

[facelessuser]

Decided to push a second beta.

1. Wanted to publish the migration guide.
2. Had one more breaking change that I'd rather push sooner rather than later.

We added a couple more color spaces and a new random color function.

At this point, we'll just let things for a while to see if we find any bugs. If none turn up, we may just pull the trigger on 1.0.

[facelessuser]

Playing with CAM16 in #212, exposed that our CAT16 matrix was posted transposed with an accidental minus sign on the first number 🤦🏻 . We'll have to get a fix out.

[facelessuser]

We are going to go ahead and release the RC1. I hadn't planned on so many changes during the beta, but I think the project is better now because of the changes. Tagging the RC will force me to stop tinkering as well 🙃. It was a much longer road to 1.0 than I had originally planned, but I think we are really close to calling it final.

[facelessuser]

I think the next release will be the final. I don't plan on releasing an RC2. We swapped out Bezier interpolation for B-spline as it is much, much better. I'm ready to be done.

[facelessuser]

Done