Marketing Releases

[davewasmer]

Rendered

[rwjblue]

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...

[locks]

can you spell out semver?

[locks]

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

[locks]

"repeated" may

[locks]

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

[davewasmer]

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.

[locks]

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?

[davewasmer]

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]

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]

@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]

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]

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]

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]

@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]

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]

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

[locks]

I second @rwjblue.

[Gaurav0]

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]

@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]

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]

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]

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

[davewasmer]

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