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...
Search
Amber Brown (HawkOwl)
August 14, 2016
Technology
1
140
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
480
Why Twisted Is The Best (WOOTConf @ LCA 2017)
hawkowl
0
150
Falsehoods Developers Have About Identity (PyCon AU 2016 Lightning Talk)
hawkowl
1
770
The Report of Twisted's Death; or Twisted & Tornado in the Asyncio Age (EuroPython 2016)
hawkowl
0
150
An Asynchronous, Scalable Django with Twisted (PyCon TW 2016 Keynote)
hawkowl
0
180
The Report of Twisted's Death; or Twisted & Tornado in the Asyncio Age (PyCon US 2016)
hawkowl
0
180
Twisted & Python 3 (Python Language Summit, 2016)
hawkowl
0
160
The Report of Twisted's Death; or Twisted & Tornado in the Asyncio Age (Perth Django Meetup)
hawkowl
0
160
The Future of Twisted, and Pretty Much Everything Else (PyCon CZ Keynote, 2015)
hawkowl
0
130
Other Decks in Technology
See All in Technology
AI専用のリンターを作る #yumemi_patch
bengo4com
4
2.2k
Zephyr RTOSを使った開発コンペに参加した件
iotengineer22
1
160
ネットワーク保護はどう変わるのか?re:Inforce 2025最新アップデート解説
tokushun
0
150
OPENLOGI Company Profile
hr01
0
67k
プロダクトエンジニアリング組織への歩み、その現在地 / Our journey to becoming a product engineering organization
hiro_torii
0
140
250627 関西Ruby会議08 前夜祭 RejectKaigi「DJ on Ruby Ver.0.1」
msykd
PRO
2
370
5min GuardDuty Extended Threat Detection EKS
takakuni
0
180
生成AI開発案件におけるClineの業務活用事例とTips
shinya337
0
190
mrubyと micro-ROSが繋ぐロボットの世界
kishima
2
380
WordPressから ヘッドレスCMSへ! Storyblokへの移行プロセス
nyata
0
350
ハッカソン by 生成AIハッカソンvol.05
1ftseabass
PRO
0
150
Amazon Bedrockで実現する 新たな学習体験
kzkmaeda
2
690
Featured
See All Featured
Into the Great Unknown - MozCon
thekraken
39
1.9k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.4k
Testing 201, or: Great Expectations
jmmastey
42
7.6k
Build your cross-platform service in a week with App Engine
jlugia
231
18k
The Pragmatic Product Professional
lauravandoore
35
6.7k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
32
2.4k
Thoughts on Productivity
jonyablonski
69
4.7k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
29
9.5k
Designing for Performance
lara
609
69k
Code Review Best Practice
trishagee
69
18k
Side Projects
sachag
455
42k
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)