marginalia
marginalia copied to clipboard
minad
Stable release
@oantolin What do you think about tagging a stable 1.0 release of Marginalia and the other completion related packages? Recently I fixed most of the important open issues in Consult and Vertico. One could tag a 1.0 in a month if nothing else comes up. The same applies to Consult, Corfu, Vertico, Orderless and Embark. Orderless is rock solid and also the Embark API seems mostly fixed now? Of course we don't have to keep the packages in sync but I think it would be nice to give the set of packages the symbolic stamp of stability and many people use our packages together or a subset of our packages. :)
I think you should consider if you want any version number compatibility guarantees going forward. Like major versions work together. So in the future if you change something in the way that say consult and embark work together you can say you need 3.x of each. If that happens I'd think you'd want to bump up marginalia to 3.x too even if it hasn't changed much? Or maybe you wouldn't (I defer that to you guys), but I think this is the stuff to consider now, if you're deciding to go 1.0.
@hmelman I don't think we want to give any such guarantees. It also doesn't make sense. The libraries are decoupled after all. The "stability label" is meant for the individual packages. It just happens that a few of them reach stable status at the same time. One could also take Corfu from the list above since I consider it less stable than Vertico. Also my Affe, Cape and Tempel packages are not on the list since they are newer and haven't seen much usage yet.
My assessment regarding the status of the completion related packages is like this:
Stable: Marginalia, Vertico, Consult, Orderless Mostly stable: Embark, Corfu Unstable: Tempel, Cape Experimental: Affe
But of course @oantolin can say more about his packages.
Anyway we are not there yet. For example in the last few months I tagged minor Vertico releases and I still changed something just now. But if things stay as is for a bit longer I think it is stable.
I agree with your assessment of the relative stability of the various packages, and I do think a 1.0 for the stable and mostly stable in the near future is desirable.
I think @hmelman has a good point, that in case of some unforseen coordinated major change we should be quick to say which versions of the packages you need to ensure they work well together, but I don't think it is necessary for that to be expressed by bumping all version numbers simultaneously. The packages are fairly well decoupled, so a major simultaneous change is not very likely and if such a change does occur it would mostly likely affect only a couple of packages (probably embark and consult, as in your example, @hmelman) and they would continue to work with any reasonably recent versions of the others. So I'd handle a case like that just in documentation.
The packages on @minad's stable list could probably tag a 1.0 right now, but it may be prudent to wait as suggested.
On the other hand for Embark I think I'd want to get three not-so-small things in before a 1.0: (1) better revert support for exports from consult async commands, (2) revert support in collect buffers too, (3) group-function support. I think after that a 1.0 would be very reasonable. And points (1) and (2) may require some small internal changes to consult to do robustly, so it might be nice if Consult 1.0 already included such changes.
@oantolin Yes, it would be nice to solve the revert support in Embark. I don't consider the group-function and some other issues as important. These are more gimmicks and could go as well into another version. I think it is most important to fix bugs and some rough edges.
What do you think about solving the revert problem in a simpler way - what if we don't support reverting for Consult Async commands, but instead do the following when reverting?
- Close the grep/snapshot buffer
- Restart the command with the input
- Let the user do the rest
This special behavior could be configurable per command or completion category via an exclusion configuration variable. For normal synchronous completion commands revert of snapshot/export should simply work (there shouldn't be an issue?). The advantage of this is also that one could reedit the input. I think it makes sense to provide two commands anyway
- revert-buffer
- embark-collect-edit/embark-export-edit
and for async commands revert-buffer would just be the same as embark-collect-edit/embark-export-edit.
I tagged minor releases of Consult, Corfu and Vertico, since these packages changed quite a bit in recent days. But if no additional big refactorings come up, I plan that the next releases will get the version 1.0.
Embark is also a bit in flux. On the other hand I could probably tag an Orderless 1.0 right now.
Yes, Orderless seems ready for 1.0 since it is probably the most mature package of the set. My approach regarding the other packages is just to wait until no big changes came in for circa a month, then they are ready.
@oantolin I just looked at the Orderless issue tracker and there it seems that most issues can just be closed since they are either outdated, not relevant anymore or resolved. On the Embark tracker there are still a few bugs left, but nothing really serious. Some of the other issues are rather ideas for features and minor UI improvements. The questions if if one wants to tag a 1.0 if there are still bugs left. In the case of Consult etc I try to reduce these to a minimum, but I am also kind of cheating by just declaring Windows bugs as wontfix :-P
Embark now has the features I said I wanted before a 1.0, so I'm happy to go into wait/bugfix mode for a while and tag a 1.0 if nothing really big changes.
Finally done, see https://github.com/minad/marginalia/commit/4c8f6b8848cc47d70431adb74864967cc5986895.