What are the criteria for reaching a 1.0 version?
Is there an estimated timeline for that milestone?
A 1.0 version doesn’t have to be feature-complete, but guarantees backward compatibility and reasonable deprecation protocol
To my knowledge there are several things that the team definitely wants to ship before 1.0. The most important include the math mode overhaul, custom types and type hints, overhaul of the styling system (including revokable set and show rules as well as some kind of fragment styling/composing (i don’t quite find the correct wording for this; but can recommend the talk about this.)).
You can also have a look at the roadmap which includes some of the points above: Roadmap - Typst Documentation
Iirc at some point there have been thoughts about removing the content type in the future. Some of the serious ideas for type hints would introduce fundamental syntax changes etc. Just as an example to make clear how substantial some of the ideas of the core developers are and that they want to put a good amount of effort into thinking through the future system.
These big chunks are by no means purely additive features but change the foundations for typst, so they should be set before 1.0.
And then there is also the question “What actually is backwards compatible in the sense of typesetting”? Almost every change influences the layout in some way.
On a side note: iirc laurenz mentioned at some point that in his opinion typst does not need to be final with a 1.x version. He likes the idea of semver. But he is inclined to work on a 2.0 version for typst after 1.x eventually iirc.
(I am just a bystander and don’t know anything about typst’s code base. I just picked up some of this information from blog posts, community calls and the discord server and I may well be misremembering some of these things entirely.)
(You may want to edit the post title so that it doesn’t bait people.)
6 Likes
Just for completeness: in this blog post, Laurenz addresses exactly that question. It is, in my eyes, the most authoritative answer you can expect.
3 Likes
Thanks
- changed the title
- I am familiar with the roadmap page. the most intriguing topic is “type hints”. Are there any initial proposals, partial specs for review?
There’s been a lot of discussion.
It sounds like this will happen after removal of content type, although some proposals still make the distinction between types with a default show rule (which can therefore be treated as content) and those that don’t have one. So content might end up still being meaningful in type annotations, but type(...) would never return content anymore, it would generally return an element function.
We’re probably getting union types (list | enum) and refinement types (heading(level: 1) at least.
I’m not sure whether we’re getting typed arrays and dicts.
There’s a challenge of syntax though, since binding: type would be the expected syntax, but that’s already used. Optional/named arguments might have the syntax changed to binding = default to accommodate this.
I hope these issues are settled soon, since even with minimal impact to the casual writer these deep changes can hold back development of external tooling as well as adoption by publishing houses
1 Like
I am pretty sure that there will be major breaking changes e.g. with the way how show rules work or the discussed syntax for type annotations. In the end it will be neccessary to rewrite almost every package from scratch, but I consider that a good thing. (And whether this breaks existing documents is something that can be mitigated as stated in laurenz’ ‘evolving typst’ blog post.)
I hope these issues are settled soon, since [… this will …] hold back development of external tooling as well as adoption by publishing houses
And yes, you’re probably right that this will stall the development of tooling and hold back adoption. But I don’t see this as a problem either. Instead I would encourage the team to take their time and explore different solutions and develop the best possible implementation they can think of. This will benefit typst in the long term and make it future proof (so that there won’t be neccessity for another typst-like project that aims to make document generation easier).
I personally, don’t have a problem with waiting two additional years until typst is accecpted by journals or it becomes more mainstream, because i am 100% sure that it will eventually become the mainstream after 1.0. Taking more time won’t change that.
4 Likes