What's stopping 1.0?

[Lokathor]

What problems does the crate have that are blockers for issuing a 1.0.0 version?

[alexcrichton]

Nothing that I know of, I have largely just not had the desire to upset the ecosystem using this crate and make everyone think they need to upgrade. It doesn't seem worth the effort when there are parallel efforts to include this in libstd.

[Lokathor]

Ah, I was not aware of efforts to include this in libstd.

[Xanewok]

See rust-lang/rust#57446, which I believe is related.

And also rust-lang/rust#59443 but that PR was closed with no explicit future direction.

[Lokathor]

Interesting! Subscribed to that. In the meantime I just put a similar macro in one of my 1.x crates.

[Veetaha]

So does it mean this crate is never going to be 1.0? From my viewpoint, it's better to transition to 1.0 earlier than never. It won't be hard because this should be backward-compatible. The more we wait the more crates use 0.1.10 version...

[Lokathor]

Honestly the 1.0 doesn't even have to semver trick back onto the 0.1.10 version to begin with. This is a compile time macro, compat between crates isn't an issue because people don't (generally) export this from a crate for other crates to use.

The main reason for 1.0 is to take a firm stance that the crate is production ready and intended to stay that way for quite a while.

[alexcrichton]

I don't have anything to add over what I mentioned previously. That will always be true though and is largely just something to acknowledge rather than deter a 1.0 release. I think it would probably be fine at this point to just bump the crate to 1.0.

[Lokathor]

@alexcrichton do you have a link to any sort of tracking issue to get cfg-if into the standard library?

[alexcrichton]

rust-lang/rust#59443, mentioned previously, is the only discussion that I'm aware of

[alexcrichton]

I've gone ahead and bumped this to 1.0