4 ms·
There's a lot of "not finished so wasn't included in this release" in the release notes. With, say, a 12 week cycle instead of 6 weeks, I'm waiting 3 months fo
by pdpi 10y ago
There's a lot of "not finished so wasn't included in this release" in the release notes.
With, say, a 12 week cycle instead of 6 weeks, I'm waiting 3 months for My feature to land in the next release, and I feel a lot more pressure to get it done now than I would with a 6-week cycle where missing a release isn't a big deal.
Assuming the team has the release process we'll automated and cutting a release doesn't add a lot of work, then there's not much to lose with this cycle.
- user5994461 10y agoMissing a release should never be a worry. People can always wait. having stable release with no regression > releasing fast
- malnourish 10y agoMaybe for a language but sometimes you need to release /now/. Sometimes we need to incur tech debt. It's a tradeoff between principle and reality.
- user5994461 10y agoYou never need to release now. Well, unless you made a huge regression that's killing your users... which ironically is a recurring issue alleviated by releasing slower and testing better, not by releasing faster :D
- majewsky 10y agoActually, releasing faster might help avoid regressions since a faster release cycle requires you to focus more on continuous testing practices. With, say, one release every 2 years, you can easily put off testing until a few weeks before the release, at which point regressions are found and panic ensues. If you release every few weeks, you need to be testing all the time to find regressions in time, so you will be forced to automate it. See, for example, this recent article on why web browsers switched to a more rapid release schedule: https://arstechnica.com/information-technology/2017/04/mozilla-microsoft-rebuilding-their-browsers-foundations-without-anyone-noticing/ https://arstechnica.com/information-technology/2017/04/mozil...
- dbaupp 10y ago"should" is a nice ideal, but people will feel pressure, especially for tooling like a compiler that other teams depend on, where slipping schedule means slipping their schedule too. Shipping more often lessens this, by meaning a missed release costs much less time. Empirically, Rust has done a pretty good job of shipping fast and not releasing regressions, so it seems like this isn't mutually exclusive.
- majewsky 10y agoI think that those few people who rely on the newest-possible features in the compiler will be compiling with a nightly build anyway (possibly pinning to a known-good version until the next release). That's actually somewhat a meme within Rust, at least as far as my impression from the outside goes. There apparently were times where most interesting crates required some unfinished feature and thus a fairly recent nightly build of the compiler and/or Cargo. I believe that problem has decreased in the meantime, but as I said, I'm looking into Rust from the outside only and don't have much own experience.
- dbaupp 10y agoAccording to the developer survey last year, most of the community is using a stable compiler in some form[0]. I can only imagine that the ratio has improved since then, especially with custom derives in 1.15. Additionally, I semiregularly see people say that they don't use nightly in production, even if they're using it for preview/experiments/testing. [0]: https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2016.html#using-rust https://blog.rust-lang.org/2016/06/30/State-of-Rust-Survey-2...