4 ms·

> Breaking changes will basically cease, with the exception of a list of libraries that are still unstable It's worth noting that this is a significant point;

> Breaking changes will basically cease, with the exception of a list of libraries that are still unstable It's worth noting that this is a significant point; probably 40-50% of the standard library is 'unstable'. You should expect breaking changes often during the alpha. It's just ridiculous to pretend otherwise. I'm not really a fan of these 'artificial deadlines'. There was no reason today had to be the alpha, other than it was previously said that it would be. There's been a lot of great work going into this release, but the standard library is not ready; it's going to under going some major changes over the next few weeks. I don't really see the point in hitting the alpha 1.0 now, with the library in it's current state.

steveklabnik 12y ago
The 45% number is misleading, because that's a per-item count. The majority of almost every module is stable, just some of the internals haven't been marked as such yet. In addition, the three modules which will see changes have RFCS that are in their final stages, so they will also stabilize soon. The alpha was always about language items, and an initial commitment to some degree of stability. Beta is the release where things are expected to be in their final form.
- deleted 12y ago
  [deleted]
- shadowmint 12y ago
  If the majority of the modules are already stable, why not wait until they are marked as stable, with a more realistic set of #[unstable] in the standard library for the alpha release? Anyone using the alpha now is being smashed with pointless unstable warnings until they add #![allow(unstable)] ...which basically negates the point of having the lint at all. Surely a better approach would be; if 'we have no idea where it's at at the moment', don't tag the api as unstable. Tag things which wont make it into 1.0 as unstable, so people start getting meaningful warnings about using api features that won't make it into 1.0. Seriously, what tangible benefit do 90 warnings about every single api have when you run a compile? Even if that number slowly drops over the coming weeks, it's still going to be entirely meaningless as an indicator of what will or will not be broken once the beta hits; you're also going to be getting a lot of rubbish feedback from people asking for certain apis (which will be stable for 1.0) to be stable, because of warnings that they're unstable; for example std::fmt. ...while anyone using say, std::raw::TraitObject, or say, alloc::heap::allocate, needs to get a heads up now that they needs to say something and get involved if they want those apis to make it into 1.0 Practically speaking, it feels like you need to roll back to 'unstable' and 'experimental' tags, with the lint warning about experimental, and ignoring unstable. ie. 'unstable' <--- Probably in 1.0, not final yet, don't lint these. 'experimental' <---- wont be in 1.0, lint on these
erikpukinskis 12y ago
Traditionally alpha just means something works. Proofs of concept are often called alpha. Beta means things mostly work, although there can still be many known blocking bugs. Late in the beta* series you would expect true stability to emerge. The release candidates are the first signal of actual stability, maybe.

steveklabnik 12y ago

The 45% number is misleading, because that's a per-item count. The majority of almost every module is stable, just some of the internals haven't been marked as such yet. In addition, the three modules which will see changes have RFCS that are in their final stages, so they will also stabilize soon. The alpha was always about language items, and an initial commitment to some degree of stability. Beta is the release where things are expected to be in their final form.

deleted 12y ago
[deleted]
shadowmint 12y ago
If the majority of the modules are already stable, why not wait until they are marked as stable, with a more realistic set of #[unstable] in the standard library for the alpha release? Anyone using the alpha now is being smashed with pointless unstable warnings until they add #![allow(unstable)] ...which basically negates the point of having the lint at all. Surely a better approach would be; if 'we have no idea where it's at at the moment', don't tag the api as unstable. Tag things which wont make it into 1.0 as unstable, so people start getting meaningful warnings about using api features that won't make it into 1.0. Seriously, what tangible benefit do 90 warnings about every single api have when you run a compile? Even if that number slowly drops over the coming weeks, it's still going to be entirely meaningless as an indicator of what will or will not be broken once the beta hits; you're also going to be getting a lot of rubbish feedback from people asking for certain apis (which will be stable for 1.0) to be stable, because of warnings that they're unstable; for example std::fmt. ...while anyone using say, std::raw::TraitObject, or say, alloc::heap::allocate, needs to get a heads up now that they needs to say something and get involved if they want those apis to make it into 1.0 Practically speaking, it feels like you need to roll back to 'unstable' and 'experimental' tags, with the lint warning about experimental, and ignoring unstable. ie. 'unstable' <--- Probably in 1.0, not final yet, don't lint these. 'experimental' <---- wont be in 1.0, lint on these

erikpukinskis 12y ago

Traditionally alpha just means something works. Proofs of concept are often called alpha. Beta means things mostly work, although there can still be many known blocking bugs. Late in the beta* series you would expect true stability to emerge. The release candidates are the first signal of actual stability, maybe.