Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Marketing Releases #259

Closed
wants to merge 4 commits into from
Closed

Conversation

davewasmer
Copy link
Contributor

@davewasmer davewasmer commented Oct 11, 2017

@rwjblue
Copy link
Member

rwjblue commented Oct 12, 2017

I like it (generally speaking). I'm somewhat leaning towards the alternative that @acorncom suggested (e.g. LTS's are "named"), but can definitely see the pro's and con's there...


# Summary

Add "named releases" to allow for easier marketing efforts while simultaneously maintaining Ember's strong semver guarantees.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you spell out semver?


# 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe spell out, link to the semver website, and then (semver) and use the shorthand for the rest of the RFC?


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).
Copy link
Contributor

@locks locks Oct 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"repeated" may


# Detailed design

> Note: this is one possible approach to marketing releases - others are discussed in the Alternatives section below
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is explicit in the RFC design, so maybe unnecessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to indicate that there are really two sides to this RFC - "marketing releases" and "named releases". Named releases are one possible implementation of marketing releases, but you can be 👍 on marketing releases and 👎 on named releases. But if that's already clear / implied by the RFC process, happy to pull this.


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 ...
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this doesn't need to be a note, and I think some more detail is warranted. how/where will the community suggest a named release? issue in this repo? does it need a full RFC? do we create a new type of RFC?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My suggestion here (probably poorly articulated) is that we purposefully don't have a formal process around this. I didn't see much value. My guess is that anyone who would be proposing a release as a named release could easily contact a core team member / drop in Slack / ping on Twitter / etc.

Basically I think it's a bit of premature optimization to add formality to this part. If it becomes problematic in the future - easy to add. But process tends to be harder to roll back than to implement.

@courajs
Copy link

courajs commented Oct 12, 2017

But what about when we run out of letters!! 😱
(just kidding, I don't think starting over after 26 releases would be too confusing)

I think named releases gives a much stronger mental anchor than version numbers. I have no idea what was introduced in Firefox 42, but Firefox Quantum is really cool!

I like the idea of choosing to name a release when we have a cohesive story to tell. If we tie to LTS releases, we may run into the same issue as today, where a named release ends up not being that exciting.

@locks
Copy link
Contributor

locks commented Oct 12, 2017

@courajs, possibly accidentally, made a good point against the alphabetical ordering of the releases:

I have no idea what was introduced in Firefox 42, but Firefox Quantum is really cool!

I think it would be better to have a related/cool name than following the alphabetical restriction.

@acorncom
Copy link
Contributor

Two thoughts:

  1. As far as naming of releases goes, I wonder about doing it every other LTS (which would work out to about every 6 months). That's likely to be long enough that there will be new features in the framework and/or good progress on new features that can be discussed. Seems like it could also help to have a somewhat regular cadence of "marketing" releases that would hit the news periodically. I think it'd be wise to do these types of marketing releases on releases that we're already going to vet a tad more carefully (i.e. we didn't ship Glimmer 2 with 2.8 because it was an LTS, but waited until 2.9/2.10 to ship the changes) so that core doesn't end up with another release that has to be carefully checked / planned for and planned around.

  2. As far as how names are chosen, not sure if this would past muster with @wifelette on brand stuff, but I wonder about using city names as our naming theme. We could choose from the list of meet ups (https://emberjs.com/mascots/?filter=meetup) and it would then give us pre-done mascots that we could use as part of the release and that would help with branding.

Let's say our release was called "Ember London". We could then use the London Tomster, do a one-two question interview with the meetup organizers (asking about how long they've done their meetup and what prominent uses of Ember occur within their meetup) and then shift to our more regular release notes / marketing pitch for Ember.

Doing things this way would allow us to highlight the global nature of Ember and its community (i.e. would be wise to not just pick US cities off the list), could allow us to pitch to different audiences (I imagine the London market and users there are very different from Washington DC users) and could highlight the stability of Ember over time. Quotes about "our meetup has been meeting for the last 3 yrs" sounds good and stable. It sounds even better when combined with "and we've got companies in our meetup who have used Ember for the last 3 yrs and they still love it" ...

@davewasmer
Copy link
Contributor Author

As far as naming of releases goes, I wonder about doing it every other LTS (which would work out to about every 6 months).

My concern with this approach is the timing. The purpose of marketing releases is to generate interest and build a little - dare I say it - hype (😱 ). If Ember releases a new rendering engine called Shimmer, and we have to wait 4 months before it hits a "marketing release", the window of novelty and hype will have long past.

I worry such a restriction will greatly reduce the marketing potential for features released early in the "marketing cycle". Or, conversely, that it would lead to attempts to time feature development around marketing releases. And with a 6 month gap between marketing releases, that leads to the kinds of crunch time that our train release schedule is designed to avoid.

so that core doesn't end up with another release that has to be carefully checked / planned for and planned around

I think this is a valid concern, but I actually think these marketing releases shouldn't warrant significantly greater scrutiny. I think the goal is to drive some of that novelty and hype around Ember, and new features sometimes mean new bugs. I've rarely encountered showstopping bugs in Ember releases as it is (a testament to the team's hard work).

using city names as our naming theme

I like it 🏙

@acorncom
Copy link
Contributor

If Ember releases a new rendering engine called Shimmer, and we have to wait 4 months before it hits a "marketing release", the window of novelty and hype will have long past.

Fair point. I don't have strong opinions here, other than that in the midst of unlocking marketing stuff I'd like to avoid adding a significant burden for core team folks in the process. They're already working hard enough

@acorncom
Copy link
Contributor

acorncom commented Dec 11, 2017

@davewasmer given @tomdale's recent comment about the core team considering Rust-like epochs for some of this signaling (#276 (comment)), how would you articulate the distinctions between named releases and epochs? Do you still see named releases as having a major value for marketing in the scenario that epochs get adopted?

@davewasmer
Copy link
Contributor Author

Probably not - there's too much conceptual overlap, so I'd see marketing releases as not adding enough value for their mental overhead if epochs were in use.

I'd love to get some direction on this RFC - if epochs are the way to go, should I rewrite this RFC? Or is that something being discussed outside the RFC process, and I should just close this?

@rwjblue
Copy link
Member

rwjblue commented Dec 11, 2017

IMHO, they are the same thing. If we have epochs and give them names, we have implemented this RFC. 🤔😝

@locks
Copy link
Contributor

locks commented Dec 11, 2017

I second @rwjblue.

@Gaurav0
Copy link
Contributor

Gaurav0 commented Dec 12, 2017

Sorry I'm late to the party, just wanted to add one thing: I would actually prefer we limit new features introduced in LTS releases and avoid making them marketing releases. I would like LTS releases generally to be more stable than regular minor versions.

@tomdale
Copy link
Member

tomdale commented Dec 14, 2017

@davewasmer Sorry for not providing feedback on this earlier; it's been on my list!

I think there are two separate issues we should try to untangle:

  1. How do we make sure the guides, API docs, blueprints, and zeitgeist reflect the current thinking about "the Ember Way"?
  2. How do we give people an opportunity to re-evaluate Ember once we land major new features, i.e., how do we do marketing?

For me, I think the first item (how do we maintain a coherent model for learners?) is most important.

While I am obviously pro-marketing, my experience is that features tend to stand alone. If anything, I've noticed many conference organizers subtly or not-so-subtly telling me they are moving away from generic "Framework X is great" talks. If we focus our marketing efforts around specific features, we can talk about the benefits of the new approach with less risk of coming off as framework cheerleaders. I think that ends up making the pitch for Ember feel more authentic.

That said, there can be groups of features that work together to be greater than the sum of their parts. Having a name for those initiatives is important. In terms of named Ember releases though, I think I'm interested in solving the learning/coherence problem first, because we may discover that it naturally solves the marketing problem at the same time.

Edit: Reading comments above, I have no objection to providing names to epochs and explicitly saying we are going to use them in documentation, marketing, etc. I would prefer not to have a set cadence for epochs/named releases. In software, you can ship based on features or you can ship based on deadlines, but not both. The six week release cycle and LTS cadence helps us stay disciplined about cutting features so we don't miss deadlines. Epochs/named releases let us have our cake and eat it too, by creating releases based on the set of features they ship with. But because we're choosing epochs based on features, we can deduce that they cannot have a deadline component to them. I think that means that the idea of scheduled epochs/named releases is not something we can do; as @davewasmer says in the RFC, declaring an epoch should be at the core team's discretion.

@davewasmer
Copy link
Contributor Author

For me, I think the first item (how do we maintain a coherent model for learners?) is most important.

From my admittedly limited perspective, the marketing problem is more critical at the moment. I think the State of JS survey (for whatever it's flaws) is telling in this regard: Ember has the largest percentage of "heard of it and not interested", by a significant margin.

No matter how good the guides/docs/blueprints/etc are, if no one wants to try Ember, it doesn't matter. And it seems that too many people dismiss Ember without even trying it at the moment - that sounds like a marketing problem.

Again, all this is from my own limited perspective, so if others with broader experience in the community feel differently, it's probably wise to give their thoughts more weight.

I think I'm interested in solving the learning/coherence problem first, because we may discover that it naturally solves the marketing problem at the same time.

Would you care to elaborate on this? I'm curious what mechanisms you have in mind there. Is it simply that you think improving Ember's learning experience would improve it's reputation to the point of encouraging more people to try it?

I would prefer not to have a set cadence for epochs/named releases.

Definitely. If anything, I would encourage named releases to be named close to - or even shortly after - their release, precisely to avoid this kind of subtle scheduling pressure.

@knownasilya
Copy link
Contributor

knownasilya commented Jul 30, 2018

Looks like Rust is doing something similar, they are calling them "editions", but using years, so 2015, 2018, etc. See https://blog.rust-lang.org/2018/07/27/what-is-rust-2018.html for the details.

@rwjblue
Copy link
Member

rwjblue commented Sep 7, 2018

@davewasmer - Can you confirm if this should be closed (or not) in favor of #371?

@davewasmer
Copy link
Contributor Author

Good catch, yea, this should be closed. Thanks @rwjblue

@davewasmer davewasmer closed this Sep 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants