A few more changes based on feedback

Author: nekevss

blog/authors.yml

@@ -1,3 +1,6 @@
 boa-dev:
   name: Boa Developers
   url: https://github.com/boa-dev
+temporal-dev:
+  name: Temporal_rs Developers
+  url: https://github.com/boa-dev/temporal

blog/temporal-release/img/temporal-dependencies.png

@@ -1,21 +1,34 @@
-# Temporal_rs release v0.1
+---
+layout: post
+tags: [post]
+title: "Temporal_rs v0.1 release"
+description:
+  Powering the new date/time API in Boa, Kiesel, V8, and any Rust
+  projects near you!
+authors: temporal-dev
+---
 
 After almost 2+ years of development, we're pleased to announce the 0.1
 release of `temporal_rs`. A calendar and time zone aware Rust date/time
-library based on ECMAScript's Temporal API.
+library based on ECMAScript's [Temporal API][mdn].
 
 `temporal_rs` is a highly conformant implementation of the Temporal API
 in Rust that can be used in native Rust code or embedded into ECMAScript
-engines / interpreters to support their implementations.
+engines / interpreters to support their implementations, which we first
+announced in our first
+[Temporal blog post](../2025-06-15-temporal-impl-1.md), if you're
+interested in learning more about small implementation details.
 
-Currently, `temporal_rs` is being used by Boa, Kiesel, V8, and Yavashark
-for their Temporal implementations (but more on that later).
+Currently, `temporal_rs` is being used by Boa, [Kiesel][kiesel-site],
+[V8][v8-site], and [Yavashark][yavashark-repo] for their Temporal
+implementations (more on that later) and will soon being
+[shipping in Chrome](https://chromestatus.com/feature/5668291307634688).
 
 To celebrate the 0.1 release of `temporal_rs`, we'll cover a short
 background of the Temporal implementation in Boa and why `temporal_rs`
-was split into it's own crate, we'll go over the libraries general
-design, then we'll walk through a couple brief examples of using
-`temporal_rs`, and finally we'll talk about the FFI and engine adoption.
+was split into it's own crate, we'll go over the library's general
+design, and then we'll walk through a couple brief examples of using
+`temporal_rs` before finally talking about the FFI and engine adoption.
 
 ## Some background and history
 
@@ -119,7 +132,8 @@ its not interesting.
 
 The Temporal API focuses on a group of 8 date and time types, each of
 which corresponds to a different aspect of date and time with varying
-support for `Calendar`s and `TimeZone`s.
+support for calendars and time zones, which are, unsurprisingly,
+represented in `temporal_rs` by the `Calendar` and `TimeZone` types.
 
 | Temporal type  | Category                          | Calendar support | Time zone support |
 | -------------- | --------------------------------- | ---------------- | ----------------- |
@@ -143,6 +157,9 @@ date accessors. The exception being PlainYearMonth and PlainMonthDay
 which are missing their day and year, respectively ... for all intents
 and purposes.
 
+For a full view of the API, we recommend checking our
+[documentation](https://docs.rs/temporal_rs/latest/temporal_rs/).
+
 ## `temporal_rs` design overview
 
 `temporal_rs` in general implements large portions of the specification
@@ -239,7 +256,7 @@ features.
 use temporal_rs::Temporal;
 
 // Get today's date
-let today = Temporal::now().to_plain_date_iso(None).unwrap()
+let today = Temporal::now().plain_date_iso(None).unwrap()
 ```
 
 #### Date operation's available
@@ -306,21 +323,19 @@ println!("{today_coptic}");
 ```
 
 While we can extend these examples further, a more fun exercise for the
-reader would be taking a look at the
-[Temporal cookbook](https://tc39.es/proposal-temporal/docs/cookbook.html)
-as it displays the utility of the Temporal API using JavaScript and all
-of these examples are now usable from Rust as well.
+reader would be taking a look at the [Temporal cookbook][cookbook] as it
+displays the utility of the Temporal API using JavaScript and all of
+these examples are now usable from Rust as well.
 
 ## FFI and engine adoption
 
 As previously stated, `temporal_rs` is used in Boa, Kiesel, and V8.
 There's just one thing, the latter of the two are ECMAScript
 implementations written in Zig and C++, respectively, not Rust. This was
-made possible through `temporal_rs`'s sister crate `temporal_capi`, a
-FFI library that provides C and C++ bindings to `temporal_rs`.
+made possible through `temporal_rs`'s FFI crate `temporal_capi`, which
+provides C and C++ bindings to `temporal_rs`.
 
-The bindings are autogenerated via
-[Diplomat](https://github.com/rust-diplomat/diplomat), which is a
+The bindings are autogenerated via [Diplomat][diplomat-repo], which is a
 project for generating FFI definitions for Rust libraries. In general,
 it's a really cool project and would definitely recommend checking it
 out if you're looking to generate FFI bindings for other languages for
@@ -329,10 +344,10 @@ your Rust library.
 There is some added benefits to offering C and C++ bindings beyond the
 classic: oh, let's (re)write it in Rust.
 
-First, this allows other languages and engines to benefit from Rust's
-type system and memory safety guarantees without having to rewrite
-everything in Rust. It's a more modular and incremental approach that
-provides some level of flexibility.
+First, this approach allows other languages and engines to benefit from
+Rust's type system and memory safety guarantees without having to
+rewrite everything in Rust. It's a more modular and incremental approach
+that provides some level of flexibility.
 
 Secondly, with how large the API is, `temporal_rs` streamlines the
 ability to adopt the Temporal API for any current and future
@@ -341,45 +356,61 @@ be done primarily in one place and then released downstream. While it's
 easy to say: "just use our library" to promote adoption. Seriously, just
 use the library. The Temporal API is massive from an implementation
 perspective and the glue code plus `temporal_rs` is relatively trivial
-in comparison to a fresh implementation.
+in comparison to a fresh, from scratch implementation.
 
 Third, with adoption from multiple engines, `temporal_rs` benefits via
-further test coverage beyond the native unit tests. For instance, of the
-engines that offer conformance numbers (Boa, Kiesel, and V8), all of
-them are currently north of 95% conformance with V8 reaching the highest
-at around 99% conformance. The conformance difference between the
-engines being due to the current implementation state of other features,
-i.e. Boa still hasn't completed its `Intl.DateTimeFormat` implementation
-yet so it fails all ECMA402 `toLocaleString` tests. As a result though,
-we can be fairly confident in the general correctness of `temporal_rs`,
-and any potential bugs will ideally be found and addressed fairly
-quickly.
+further test coverage beyond the native Rust unit tests. For instance,
+of the engines that offer conformance numbers (Boa, Kiesel, and V8), all
+of them are currently north of 95% conformance with V8 reaching the
+highest at around 99% conformance. The conformance difference between
+the engines being due to the current implementation state of other
+features, i.e. Boa still hasn't completed its `Intl.DateTimeFormat`
+implementation yet so it fails all ECMA402 `toLocaleString` tests. As a
+result though, we can be fairly confident in the general correctness of
+`temporal_rs`, and any potential bugs will ideally be found and
+addressed fairly quickly.
 
 In general, `temporal_rs` is a pretty good test case with reference code
-for setting up a Rust library over FFI with usage in a C++ and Zig
-codebase, so that's really cool.
+for setting up a Rust library over FFI with usage in both a C++ and Zig
+codebase.
 
 ## Conclusion
 
-The 0.1 release of `temporal_rs` is out. We expected the general API to
+The 0.1 release of `temporal_rs` is out. We expect the general API to
 remain fairly stable moving forward, with any non-patch bumps being for
 added features. Feel free to try it out, and provide feedback / file any
-issues you come across.
+issues you come across. Although, we will make changes and semantic
+versioning bumps based on feedback or the Temporal specification.
+
+Our current plan is that we hope have any remaining issues addressed and
+the API fully stable for when Temporal is accepted by tc39 and moved to
+stage 4. Once Temporal is stage 4, we will move forward with a 1.0
+release.
 
 `temporal_rs` started as an interesting experiment in creating an engine
 agnostic library of the Temporal API that could also be usable as a
 date/time library in native Rust code. We've seen pretty successful
 results from other engines adopting the library for use. And with any
-luck, it will also be useful for the Rust ecosystem as a whole.
+luck, we hope this library will also be useful for the Rust ecosystem as
+a whole as well.
 
 ## Special thanks
 
-We'd like to thank all the contributors to `temporal_rs` for helping it
-get to 0.1.
+We'd like to thank all the [contributors] to `temporal_rs` for helping
+it get to v0.1.
 
 Thanks to the University of Bergen students who helped drive some of the
 major conformance push earlier this year.
 
 Also, a huge thanks to all the Temporal champions for all their work on
 the specification as well as the ICU4X project for their incredible
 ongoing work on calendars and all things i18n datetime related.
+
+[mdn]:
+  https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal
+[v8-site]: https://v8.dev/
+[kiesel-site]: https://kiesel.dev/
+[yavashark-repo]: https://github.com/Sharktheone/yavashark
+[cookbook]: https://tc39.es/proposal-temporal/docs/cookbook.html
+[diplomat-repo]: https://github.com/rust-diplomat/diplomat
+[contributors]: https://github.com/boa-dev/temporal/graphs/contributors