You wouldn’t check this in to your code base immediately, but you could test this! Many shops do but often wait until late in the development cycle to test something out, if ever.Īt Slack, we test a number of core build tools continuously to catch regressions early and give feedback to maintainers as soon as possible and to give ourselves peace of mind updating to stable when it’s released. There’s no test as thorough as running it in your own codebase, but that’s not something library and tool maintainers can do.Ĭonsider this: most major build tools have some degree of public alpha, beta, RC, or snapshot channel to allow developers to try out new versions and features before they’re stabilized. Updating on day one can impose a risk you’re not willing to take, as you’re trusting these tools’ tests to ensure they have no regressions.
SLACK JOBS ANDROID
Updates come with inherent risk though, especially when some build tools have long release cycles like the Android Gradle Plugin (AGP) or Kotlin. Life’s too short to not use modern tools. Aside from the new features and improvements they bring, we found developers are generally happier feeling like they are using the latest and greatest. Not necessarily bleeding edge (alphas, betas, RC, etc.), but the latest stable versions. One thing we really pride ourselves in is using the latest build tools when possible. It’s multi-faceted, spreading across build speed, reliability, modernity, and more. We take developer productivity pretty seriously at Slack.
0 kommentar(er)
