Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Releasing Calendar Versioned Software (PyCon AU 2016)
Search
Amber Brown (HawkOwl)
August 14, 2016
Technology
1
120
Releasing Calendar Versioned Software (PyCon AU 2016)
Amber Brown (HawkOwl)
August 14, 2016
Tweet
Share
More Decks by Amber Brown (HawkOwl)
See All by Amber Brown (HawkOwl)
Batteries Included, But They're Leaking (Python Language Summit, 2019)
hawkowl
0
370
Why Twisted Is The Best (WOOTConf @ LCA 2017)
hawkowl
0
130
Falsehoods Developers Have About Identity (PyCon AU 2016 Lightning Talk)
hawkowl
1
670
The Report of Twisted's Death; or Twisted & Tornado in the Asyncio Age (EuroPython 2016)
hawkowl
0
130
An Asynchronous, Scalable Django with Twisted (PyCon TW 2016 Keynote)
hawkowl
0
150
The Report of Twisted's Death; or Twisted & Tornado in the Asyncio Age (PyCon US 2016)
hawkowl
0
120
Twisted & Python 3 (Python Language Summit, 2016)
hawkowl
0
150
The Report of Twisted's Death; or Twisted & Tornado in the Asyncio Age (Perth Django Meetup)
hawkowl
0
120
The Future of Twisted, and Pretty Much Everything Else (PyCon CZ Keynote, 2015)
hawkowl
0
89
Other Decks in Technology
See All in Technology
BDD(Cucumber)コミュニティが無料提供しているコンテンツの紹介と現在起きている危機
nihonbuson
4
750
統計的学習理論読み Chapter 1
kmatsui
3
930
GraphQLに入門してみた
chiroruxx
2
130
XRミーティング 2024-03-20
1ftseabass
PRO
0
100
中央集権体制からDataOpsへの転換 / centralized-to-dataops-transformation
pei0804
7
1.5k
Tohoku.Tech #1 「EC-CUBE/AWSの構築をChatGPTに相談してみました」by テンダ
jun2882
0
140
今さら聞けない!? AWSの生成AIサービス Amazon Bedrock入門!
minorun365
PRO
11
2.6k
技育祭2024春 LT Finatextホールディングス
kevinrobot34
1
170
依存ライブラリはどこに?
takesection
0
110
業務で使えるかもしれない…!?GitHub Actions の Tips 集 / CI/CD Test Night #7
ponkio_o
PRO
24
7.1k
オブジェクトのおしゃべり大失敗 メッセージングアンチパターン集 / messaging anti-pattern collection
ytake
0
340
オブジェクト指向宗教史
tanakahisateru
14
12k
Featured
See All Featured
A Tale of Four Properties
chriscoyier
150
22k
Build your cross-platform service in a week with App Engine
jlugia
223
17k
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
111
35k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
6
950
How to train your dragon (web standard)
notwaldorf
71
5.1k
Building Flexible Design Systems
yeseniaperezcruz
317
37k
Done Done
chrislema
178
15k
Bash Introduction
62gerente
604
210k
Typedesign – Prime Four
hannesfritz
36
2k
5 minutes of I Can Smell Your CMS
philhawksworth
199
19k
Git: the NoSQL Database
bkeepers
PRO
421
63k
Transcript
Releasing Calendar Versioned Software PyCon Australia, 2016
Hello, I’m Amber Brown (HawkOwl)
@hawkieowl atleastfornow.net
None
I live in Perth, Western Australia but Melbourne soon...
None
@hawkieowl "Releasing Calendar Versioned Software" Release Manager for: 13.2 14.0
15.0, 15.1, 15.2, 15.3, 15.4, 15.5 16.0, 16.1, 16.2, 16.3, 16.4
@hawkieowl "Releasing Calendar Versioned Software" Other Projects twisted/treq twisted/klein twisted/pydoctor
hawkowl/rproxy
(image by isometri.cc)
Versioning
@hawkieowl "Releasing Calendar Versioned Software" Consistency in your software's characteristics
@hawkieowl "Releasing Calendar Versioned Software" trunk now != trunk later
@hawkieowl "Releasing Calendar Versioned Software" Version X now == Version
X later
@hawkieowl "Releasing Calendar Versioned Software" Upgrading to Version Y is
explicit, repeatable
@hawkieowl "Releasing Calendar Versioned Software" Different kinds of versions for
different release types
@hawkieowl "Releasing Calendar Versioned Software" Feature releases Bugfix releases Repackagings
@hawkieowl "Releasing Calendar Versioned Software" Makes your software easier to
use, deploy
@hawkieowl "Releasing Calendar Versioned Software" What do we have to
choose from?
@hawkieowl "Releasing Calendar Versioned Software" SemVer "Semantic versioning"
@hawkieowl "Releasing Calendar Versioned Software" CalVer "Calendar versioning"
@hawkieowl "Releasing Calendar Versioned Software" Chaos "meh just increment it"
@hawkieowl "Releasing Calendar Versioned Software"
SemVer
Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version
when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards-compatible manner, and 3. PATCH version when you make backwards- compatible bug fixes. - semver.org
@hawkieowl "Releasing Calendar Versioned Software" breaking.feature.bugfix
@hawkieowl "Releasing Calendar Versioned Software" 1.0.0 Initial stable release
@hawkieowl "Releasing Calendar Versioned Software" 1.1.0 Backwards-compatible feature added
@hawkieowl "Releasing Calendar Versioned Software" 1.1.1 Backwards-compatible bug fix
@hawkieowl "Releasing Calendar Versioned Software" 2.0.0 Functionality changed in a
way that breaks existing code, or removed feature
Why SemVer?
@hawkieowl "Releasing Calendar Versioned Software" Fits well with planning, roadmaps,
"top-down"
@hawkieowl "Releasing Calendar Versioned Software" Easy to see if a
release will work with your codebase
@hawkieowl "Releasing Calendar Versioned Software" package>=1.0,<2.0 Will match 1.0.0, 1.1.0,
etc Won't match 2.0, 3.2, etc
@hawkieowl "Releasing Calendar Versioned Software" Encourages developers to break APIs
more sparingly
@hawkieowl "Releasing Calendar Versioned Software" Easy for developers to understand
and use to communicate intent
Why SemVer does not fit reality
@hawkieowl "Releasing Calendar Versioned Software" Production software is too complex
to tell if any change is a breaking one
@hawkieowl "Releasing Calendar Versioned Software" No such thing as a
"safe release"
@hawkieowl "Releasing Calendar Versioned Software" Doesn't scale well to complex
software (frameworks, languages, operating systems)
@hawkieowl "Releasing Calendar Versioned Software" Chrome Versioning Syndrome
@hawkieowl "Releasing Calendar Versioned Software" Forces your whole codebase to
operate in lockstep regarding deprecations, removals
@hawkieowl "Releasing Calendar Versioned Software" "The Big 2.0" (or 3.0!)
kills projects
@hawkieowl "Releasing Calendar Versioned Software" "It's okay, we can update
the major version number" hurts your users
@hawkieowl "Releasing Calendar Versioned Software" Large userbases on old major
versions means you have to backport security fixes
@hawkieowl "Releasing Calendar Versioned Software" "Agile" developed software does not
fit a "top down" model
@hawkieowl "Releasing Calendar Versioned Software" Is there a better way
to serve our users?
CalVer
@hawkieowl "Releasing Calendar Versioned Software" Released not according to features,
but time
@hawkieowl "Releasing Calendar Versioned Software" Firm schedules: Ubuntu Django (ish)
@hawkieowl "Releasing Calendar Versioned Software" Loose schedules: Twisted/Klein/Treq, youtube_dl, pytz
@hawkieowl "Releasing Calendar Versioned Software" year.month.patch year.month.day[.patch] year.release.patch
@hawkieowl "Releasing Calendar Versioned Software" Ubuntu 16.04.1 youtube_dl 2016.08.07 Twisted
16.3.0
@hawkieowl "Releasing Calendar Versioned Software" Reduce the friction for a
user to upgrade constantly
@hawkieowl "Releasing Calendar Versioned Software" Constantly stable
@hawkieowl "Releasing Calendar Versioned Software" Promise no breaking changes without
deprecations, ever* *(or at least without a very good reason)
@hawkieowl "Releasing Calendar Versioned Software" Deprecated functionality removed after a
period of time
@hawkieowl "Releasing Calendar Versioned Software" Usually one true release (the
current one)
@hawkieowl "Releasing Calendar Versioned Software" Compatible with LTS strategies
@hawkieowl "Releasing Calendar Versioned Software" But it's not a silver
bullet
Realities of Software
@hawkieowl "Releasing Calendar Versioned Software" Bugs will happen
@hawkieowl "Releasing Calendar Versioned Software" Regressions will happen
@hawkieowl "Releasing Calendar Versioned Software" How you manage them dictates
the quality of your releases
@hawkieowl "Releasing Calendar Versioned Software" CalVer is the acceptance that
software is constantly changing
@hawkieowl "Releasing Calendar Versioned Software" Effective calver requires you adopt
better processes
@hawkieowl "Releasing Calendar Versioned Software" You must ensure every change
does not affect a public API
@hawkieowl "Releasing Calendar Versioned Software" You need processes in place
for deprecations, you'll be doing them a lot
Implementing CalVer
@hawkieowl "Releasing Calendar Versioned Software" Your goals dictate your release
schedule
@hawkieowl "Releasing Calendar Versioned Software" Strict schedules mean more dependable
upgrade cycles
@hawkieowl "Releasing Calendar Versioned Software" Strictly scheduled releases work well
when you have one or two releases/yr
@hawkieowl "Releasing Calendar Versioned Software" Operating systems, enterprise software
@hawkieowl "Releasing Calendar Versioned Software" Loose schedules mean that you
can release as often as there's features or fixes you want in the user's hands
@hawkieowl "Releasing Calendar Versioned Software" Loosely scheduled releases work well
when you want 5+ releases/yr
@hawkieowl "Releasing Calendar Versioned Software" Software that talks to external
services, software with security implications, libraries/frameworks
@hawkieowl "Releasing Calendar Versioned Software" Django has 1 release/8mo Twisted
has ~5 releases/yr, youtube_dl has 1-2 a week
Deprecation Policies
@hawkieowl "Releasing Calendar Versioned Software" Deprecation policies must scale with
your releases, plus your userbase
@hawkieowl "Releasing Calendar Versioned Software" Twisted requires 1 year of
deprecation (as long as two releases have happened in the meantime)
@hawkieowl "Releasing Calendar Versioned Software" Django requires 8-16mo of deprecation
(Django uses a semver/calver hybrid, with "LTS" releases)
Alter your QA
@hawkieowl "Releasing Calendar Versioned Software" Constantly changing software needs to
have different QA processes
@hawkieowl "Releasing Calendar Versioned Software" Compensate for the lack of
rigid alphas/betas with automated testing
@hawkieowl "Releasing Calendar Versioned Software" More tests == less likelihood
of regressions
@hawkieowl "Releasing Calendar Versioned Software" Issue release candidates and encourage
users to run their tests against it
Regressions: The Enemy of Frequent Releases
@hawkieowl "Releasing Calendar Versioned Software" Q: What is a regression?
A: When user's software stops working through no fault of their own.
@hawkieowl "Releasing Calendar Versioned Software" Python import locations Argument names
+ types Return value types Behaviour
@hawkieowl "Releasing Calendar Versioned Software" Declare that "no breaking changes"
only applies to public API!
@hawkieowl "Releasing Calendar Versioned Software" How can we introduce fewer
regressions?
Have A Clear Public API
@hawkieowl "Releasing Calendar Versioned Software" Public module.MyClass Private module._MyClass _module.MyClass
(ish*) *If _module.MyClass is accessible through a public function, it is public
@hawkieowl "Releasing Calendar Versioned Software" Abstract interfaces over concrete implementations
@hawkieowl "Releasing Calendar Versioned Software" "Returns an implementor of ISomething"
vs "Returns Something"
@hawkieowl "Releasing Calendar Versioned Software" As long as the public
API stays the same, everything else can change
@hawkieowl "Releasing Calendar Versioned Software" Test ONLY using your public
API
@hawkieowl "Releasing Calendar Versioned Software" Instead of mocks, use explicitly
passed fakes that implement the same interface as the real thing
@hawkieowl "Releasing Calendar Versioned Software" Mock-based testing means you may
hide bugs in the underlying layers!
@hawkieowl "Releasing Calendar Versioned Software" "Slow Down, Compose Yourself" Amber
Brown, PyCon AU 2015
Re-Export Functionality
@hawkieowl "Releasing Calendar Versioned Software" __all__ is a hint as
to what is exported
@hawkieowl "Releasing Calendar Versioned Software" __all__ only affects import *,
not from x import y!
@hawkieowl "Releasing Calendar Versioned Software" Write private modules, re-export into
a public one
@hawkieowl "Releasing Calendar Versioned Software" logger _observer _formatting LogPublisher LogFormatter
@hawkieowl "Releasing Calendar Versioned Software" logger LogPublisher LogFormatter
@hawkieowl "Releasing Calendar Versioned Software" Can't accidentally export implementation details
Track Your Performance
@hawkieowl "Releasing Calendar Versioned Software" Performance degredation breaks software with
performance constraints
@hawkieowl "Releasing Calendar Versioned Software" Microbenchmarks (Black Box)
@hawkieowl "Releasing Calendar Versioned Software"
@hawkieowl "Releasing Calendar Versioned Software" Macrobenchmarks (Integration)
@hawkieowl "Releasing Calendar Versioned Software"
Implement Code Review
@hawkieowl "Releasing Calendar Versioned Software" Twisted review process means we
have a lower defect/LoC than most
@hawkieowl "Releasing Calendar Versioned Software" Most of these things can't
(yet!) be detected by tools
What Aren't Regressions
@hawkieowl "Releasing Calendar Versioned Software" Security fixes
@hawkieowl "Releasing Calendar Versioned Software" Patching known vulnerabilities should be
done backwards compatibly if possible
@hawkieowl "Releasing Calendar Versioned Software" Removing outright broken code (hasn't
compiled for years, or doesn't work in dangerous ways)
@hawkieowl "Releasing Calendar Versioned Software" Have a process so that
breaking changes are as unsurprising as possible
Safely Making Breaking Changes
@hawkieowl "Releasing Calendar Versioned Software" Deprecation is how you remove
unwanted public API
@hawkieowl "Releasing Calendar Versioned Software" raise DeprecationWarning("no")
@hawkieowl "Releasing Calendar Versioned Software" @deprecated( Version("Twisted", 16, 4, 0),
"Use newfunc instead.") def oldfunc(): return "wrong"
@hawkieowl "Releasing Calendar Versioned Software" DeprecationWarning: oldfunc was deprecated in
Twisted 16.4.0: Use newfunc instead.
@hawkieowl "Releasing Calendar Versioned Software" Make old APIs shims over
new ones, if possible
@hawkieowl "Releasing Calendar Versioned Software" Encourage your users to run
Python with -Wd
@hawkieowl "Releasing Calendar Versioned Software" Remove it later, according to
your deprecation policy
@hawkieowl "Releasing Calendar Versioned Software" Don't remove too much at
once!
Tools To Help
@hawkieowl "Releasing Calendar Versioned Software" Streamline your NEWS file! github.com/hawkowl/towncrier
@hawkieowl "Releasing Calendar Versioned Software" Rich, comparable versions github.com/twisted/incremental
@hawkieowl "Releasing Calendar Versioned Software" Combine coverage between Travis, BuildBot,
AppVeyor, Jenkins, et al codecov.io
@hawkieowl "Releasing Calendar Versioned Software" Repeatable, automated testing environments tox.readthedocs.io
tl;dr: Six Steps To CalVer
Step 1: Pick what CalVer properties you want
Step 2: Have a clear "public API"
Step 3: Ensure your test suite covers all the public
API
Step 4: Release early, release often!
Step 5: If it sucks, deprecate it! ...but replace it
first
Step 6: Don't break the user's software!
Questions? (pls no statements, save them for after)