[Roadmap] Road to v1!

[JamesLMilner]

Firstly, hello anyone reading or following the repository. It's come to my mind that Terra Draw will be two years old in July, and we are still tagged in Alpha. Although this a very deliberate decision, to allow quick iteration and avoidance of the limitations of attempting to adhere to semantic versioning, I am conscious that it is realistically going to be putting people off using the library.

As such I'd want to lay out a roadmap to what a v1 iteration would look like. For me there are three main issues:

1. Allowing validations across both drawing and selecting modes (essentially feat: add validate to all built in modes #256 as we have validation in select mode already). I personally feel like the validations provide an open ended mechanism for people to allow or prevent drawing or editing of any shape in any way they see fit. We could also expose common validations that the community uses in the future.

2. Providing at least the foundations of a standardised approach to how we handle Web Mercator vs Globe based drawing. I am still working out how might be best to approach this, either at a global level (i.e. you pass a flag to Terra Draw, and then all operations will be geodesic) or if it should be more granular (i.e. a flag we pass at the mode level). There are lots of things to consider here, as an example someone may want to draw on a Web Mercator map but draw a geodesic line (i.e. via TerraDrawGreatCircle mode). Another example of such trickiness would be what the default behaviour should be - in TerraDrawCircleMode geodesic and Web Mercator circles would result in very different looking geometries when projected back and forth, which is confusing to some users (i.e. at the moment we have a geodesic circle by default, but perhaps some users expect it to be a perfect Web Mercator circle?). This issue is mostly capture by Support geodesic drawing (i.e globes) #23 but it needs fleshing out a little bit to capture the full scope.

3. Trying to bullet proofing what already exists. Essentially we want to make sure Terra Draw is as bug free and painless to use as possible. Of course, an incredibly tough endeavour, but with a combination of working on the unit and end-to-end testing and the user documentation, I am confident we can get to a good position.

4. EDIT: Splitting out adapters into their own packages. This has many benefits, firstly resolving [Bug] Library not usable without skipLibCheck: true? #350 which is a pain. The other is that it allows a sensible versioning strategy for adapters. As mapping libraries change we want to keep up with them, but also allow ways to support multiple versions of a library. Having separate packages for the adapters allows for this, and also reduces the surface area of the actual core library. This will be quite a big change and will require some small adjustments by users, but I feel it is the best option for the long term of the library.

[vladimir-velinov]

@JamesLMilner thanks for the provided roadmap. Any idea about timeline?

[JamesLMilner]

@vladimir-velinov thanks for posting - the main thing at the moment preventing release in my eyes is #350. I want to get to this soon, maybe around end of December during the holidays. Could be looking at a v1 release in Q1 of 2025.

What are you working on out of interest?

[vladimir-velinov]

@JamesLMilner Q1 2025 sounds good. We're making use of Maplibre to create reusable Web component for our apps. We already integrated TerraDraw and work really well, but we'll need it to be labeled as official release, not beta in order to go in production.

[JamesLMilner]

I've added point 4, which is to do with splitting out adapters into seprate packages. This resolves quite a few problems for Terra Draw, for example map library versioning, avoiding people having to install unnecessary devDependencies, and also helping resolve #350 .