Tracker: Release 1.0

[KodrAus]

This is a list of things we need to do before we can release a stable version of uuid.

• V1 Generator Should not Always Increment Sequence Counter #106
• Is serde implementation going to be stable? #90
• Shift into rust-lang org
  • RFC (as per https://github.com/rust-lang/rfcs/blob/master/text/1242-rust-lang-crates.md)
• set up for bors?
• Find a new home for uuid
• Ensure that we are complying with Rust API Guidelines #191
• Public dependencies:
  • [ ] Rename serde to serde1
  • [ ] Rename slog to slog2
  • Shift winapi into an external library (uuid-winapi)
  • Remove stdweb and rename wasm-bindgen to js
• 1.0.0!

[KodrAus]

@alexcrichton does that list look right to you?

[alexcrichton]

Heh I'd actually skip the last 3 steps even :)

I think it's fine to bump to 1.0 without an RFC of shifting to rust-lang, nowadays crates in the nursery tend to be relatively independent I think. We could always consult @rust-lang/libs to see if anyone disagrees!

[sfackler]

I would prefer moving uuid out of rust-lang* rather than into rust-lang.

[KodrAus]

@sfackler I think I would too. Do you have any thoughts on where it should end up living?

[sfackler]

In the hands of someone that cares about it, I guess.

[durka]

The next breaking release should have the std feature on by default, IMO.

[KodrAus]

cc @kinggoesgaming @Dylan-DPC

What do you think we need to resolve here in uuid before we're comfortable shipping a 1.0?

[Dylan-DPC-zz]

i don't think there is anything major left. We can release the next major as 1.0

[kinggoesgaming]

I think we will target 0.8 as a catch release just to ensure we didn't miss something... If everything goes good and dandy we might just bump the version of it as 1.0

[WiSaGaN]

Greetings!
Is the 1.0 release planned this year, or is there anything further we are going to wait to include since the 0.8 release?

[kinggoesgaming]

Hi @WiSaGaN, we are currently waiting on getting the points in #191 checked off. That's essentially all that is blocking 1.0 release.

There are a few breaking changes, they are not major enough to warrant a breaking minor release before 1.0 so they may be published under 1.0

[KodrAus]

We've been carrying this along for a couple years now and had a chance to explore some APIs more deeply. I think the best way to solidify confidence in the API now would be to write up something like the regex RFC for the complete public surface area, including any more changes we wanted to make. I'll spend some time on this over the next little while.

I don't think it would be worth publishing any more minor releases before 1.0, like @kinggoesgaming mentioned there isn't much else we were looking at changing, and since uuid does appear publicly in consumer APIs we should limit any more incompatible versions floating around.

[KodrAus]

I’m covering off the last breaking bits in #536. I’d like to be sure we can support #523 using our existing timestamp APIs and move winapi support into an external crate, but besides that I think we’re in good shape to stabilize.

[KodrAus]

Not much left now. We’ve just got #537 as a breaking change and need to get a release of the new proc macro ready.

Then we can do a 1.0.0-alpha to make sure everything is good for everyone and then stabilize this library!

[KodrAus]

We've now got a pre-release of 1.0.0 🎉

It'll be great to get the tyres kicking on this so we can weed out any potential issues, but unless breaking changes are necessary there won't be any difference between this release and what's stabilized as 1.0.0.

[jplatte]

I saw in the pre-release changelog that a new get_foo method was added (well, renamed from to_foo). This seems to be against the Rust API guidelines.

[KodrAus]

Yeh, that one was a niche method renamed to fit the scheme of existing methods that have been around for a long time and predate the guidelines altogether. As far as transgressions goes it’s pretty mild since it doesn’t materially affect the program. So I opted to keep a consistent scheme with minimal churn.