From 749be40416986990e751d17b396f0364dbeb69ad Mon Sep 17 00:00:00 2001 From: Dave Wasmer Date: Mon, 9 Oct 2017 13:35:52 -0600 Subject: [PATCH 1/4] add marketing-releases RFC --- text/0000-marketing-releases.md | 58 +++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 text/0000-marketing-releases.md diff --git a/text/0000-marketing-releases.md b/text/0000-marketing-releases.md new file mode 100644 index 0000000000..b78b20d03d --- /dev/null +++ b/text/0000-marketing-releases.md @@ -0,0 +1,58 @@ +- Start Date: 2017-10-09 +- RFC PR: (leave this empty) +- Ember Issue: (leave this empty) + +# Summary + +Add "named releases" to allow for easier marketing efforts while simultaneously maintaining Ember's strong semver guarantees. + +# Motivation + +Ember's commitment to semver is valuable. The practice of introducing new features in minor versions and major versions only removing deprecated functionality makes for a straightforward and predictable upgrade path. + +Unfortunately, this is not the norm throughout the JavaScript community, despite the wide usage of semver version numbering via tooling like npm. This leads to a marketing problem, as evidenced by some of the reaction to the Ember 3.0 announcement. + +For most other projects, a semver major bump is a big marketing event. Culturally, the expectations are to see great new features. For Ember, semver major bumps are comparatively lackluster - simply removing functionality that you probably have stopped using anyway. + +This may lead developers who may not fully understand our semver practices to assume that the apparently lackluster 3.0 annoucement is indicative of a lackluster project (when in reality, it's the opposite). + +This RFC proposes that we attempt to decouple semver version numbers from our marketing efforts, and adopt a different set of "marketing releases" which can be used to generate interest around new features. The goal is to find a solution that allows us to keep our strong semver guaarantees while also allowing for effective marketing of Ember's new features and advancements. + +# Detailed design + +> Note: this is one possible approach to marketing releases - others are discussed in the Alternatives section below + +Periodic minor releases are identified as containing noteworthy or marketable new features, and flagged as a "named release". Names would be chosen in alphabetical order to help communicate order, and should be simple and memorable. + +The core team must reach a consensus on whether or not to "name" a minor release, but anyone in the community may suggest it if that release is not already under consideration. + +> Note: this section was left intentionally light on process. One goal here is to avoid burdening any contributors with significant additional process. If we move forward with names releases and discover this process to be too loose, we can propose additional refinements. Premature optimization and all that ... + +# How We Teach This + +This is actually primarily a teaching & marketing tool. This would help users discover new features and advancements in Ember. Blogs and newsletters would transition to referencing release names when discussing new and upcoming features. + +# Drawbacks + +I've split this section into two parts: drawbacks to the idea of marketing releases _in any form_, and drawbacks to the specific proposal from above to attach a name to certain minor releases deemed "noteworthy enough". + +## Drawbacks to marketing releases in general + +* Identifying releases to "market" might be tricky or contentious, i.e. "3.2 has features X & Y - is that enough to justify a 'marketing' release?" +* Might not be helpful enough. With the size and history of the Ember community, the developer culture may be entrenched deeply enough in semver release numbers to change course to thinking of marketing releases. + +## Drawbacks to "named releases" specifically + +* Alphabetical named releases help convey ordinality, but not as readily as numbers might +* The alphabetical approach might be difficult with certain letters (i.e. a named release for "X") +* Named releases are only part of the solution - the rest is the actual marketing of the releases. Without effective marketing, named releases are deadweight process + +# Alternatives + +* We could not do marketing releases at all +* One minor variant of the above proposal, suggested by @acorncom: named releases correspond 1:1 with LTS releases. +* Rather than "naming" the marketing releases, suggested by @runspired: add another digit to the version number that is solely for marketing: ... + +# Unresolved questions + +N/A \ No newline at end of file From 452a783b41b7ed32b863a0c7630f8d9f312eb928 Mon Sep 17 00:00:00 2001 From: Dave Wasmer Date: Wed, 11 Oct 2017 21:54:54 -0600 Subject: [PATCH 2/4] fix typos, h/t to the esteemed @acorncom --- text/0000-marketing-releases.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-marketing-releases.md b/text/0000-marketing-releases.md index b78b20d03d..81380f3385 100644 --- a/text/0000-marketing-releases.md +++ b/text/0000-marketing-releases.md @@ -14,9 +14,9 @@ Unfortunately, this is not the norm throughout the JavaScript community, despite For most other projects, a semver major bump is a big marketing event. Culturally, the expectations are to see great new features. For Ember, semver major bumps are comparatively lackluster - simply removing functionality that you probably have stopped using anyway. -This may lead developers who may not fully understand our semver practices to assume that the apparently lackluster 3.0 annoucement is indicative of a lackluster project (when in reality, it's the opposite). +This may lead developers who may not fully understand our semver practices to assume that the apparently lackluster 3.0 announcement is indicative of a lackluster project (when in reality, it's the opposite). -This RFC proposes that we attempt to decouple semver version numbers from our marketing efforts, and adopt a different set of "marketing releases" which can be used to generate interest around new features. The goal is to find a solution that allows us to keep our strong semver guaarantees while also allowing for effective marketing of Ember's new features and advancements. +This RFC proposes that we attempt to decouple semver version numbers from our marketing efforts, and adopt a different set of "marketing releases" which can be used to generate interest around new features. The goal is to find a solution that allows us to keep our strong semver guarantees while also allowing for effective marketing of Ember's new features and advancements. # Detailed design From f155001b058091baf45738048591bc7677e535f5 Mon Sep 17 00:00:00 2001 From: Dave Wasmer Date: Thu, 12 Oct 2017 09:10:31 -0600 Subject: [PATCH 3/4] avoid assuming jargon - spell out and link to semver --- text/0000-marketing-releases.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/text/0000-marketing-releases.md b/text/0000-marketing-releases.md index 81380f3385..96f60e89f4 100644 --- a/text/0000-marketing-releases.md +++ b/text/0000-marketing-releases.md @@ -4,11 +4,11 @@ # Summary -Add "named releases" to allow for easier marketing efforts while simultaneously maintaining Ember's strong semver guarantees. +Add "named releases" to allow for easier marketing efforts while simultaneously maintaining Ember's strong semantic versioning guarantees. # Motivation -Ember's commitment to semver is valuable. The practice of introducing new features in minor versions and major versions only removing deprecated functionality makes for a straightforward and predictable upgrade path. +Ember's commitment to [semantic versioning (semver)](http://semver.org/) is valuable. The practice of introducing new features in minor versions and major versions only removing deprecated functionality makes for a straightforward and predictable upgrade path. Unfortunately, this is not the norm throughout the JavaScript community, despite the wide usage of semver version numbering via tooling like npm. This leads to a marketing problem, as evidenced by some of the reaction to the Ember 3.0 announcement. From 880a6b8a0662ce3b93dedb296ddedf5373aaee2f Mon Sep 17 00:00:00 2001 From: Dave Wasmer Date: Thu, 12 Oct 2017 09:15:42 -0600 Subject: [PATCH 4/4] reword to avoid confusion, h/t @locks --- text/0000-marketing-releases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/text/0000-marketing-releases.md b/text/0000-marketing-releases.md index 96f60e89f4..a70d823960 100644 --- a/text/0000-marketing-releases.md +++ b/text/0000-marketing-releases.md @@ -14,7 +14,7 @@ Unfortunately, this is not the norm throughout the JavaScript community, despite For most other projects, a semver major bump is a big marketing event. Culturally, the expectations are to see great new features. For Ember, semver major bumps are comparatively lackluster - simply removing functionality that you probably have stopped using anyway. -This may lead developers who may not fully understand our semver practices to assume that the apparently lackluster 3.0 announcement is indicative of a lackluster project (when in reality, it's the opposite). +This can lead developers who don't fully understand our semver practices to assume that the apparently lackluster 3.0 announcement is indicative of a lackluster project (when in reality, it's the opposite). This RFC proposes that we attempt to decouple semver version numbers from our marketing efforts, and adopt a different set of "marketing releases" which can be used to generate interest around new features. The goal is to find a solution that allows us to keep our strong semver guarantees while also allowing for effective marketing of Ember's new features and advancements.