Flesh out named releases vs. semver releases

[davewasmer]

Semver is awesome, especially when done well (i.e. deprecate & new features in minor releases, majors just remove deprecated code).

Unfortunately, from a marketing perspective, this makes for underwhelming news cycles. Cool new features come out incrementally (meaning no "big news" releases), and major version number releases (i.e. Denali 3 is out!!) are lame from a news/hype perspective (woo - things got removed?).

I think one potential solution here is to have "named" releases that are not tied to semver majors. So Denali v2.3 might be just another minor semver release, but could also be a "named" release, i.e. "Denali Blackburn", which introduces big newsworthy features. Once we have an LTS schedule in place, perhaps named releases are also LTS?

I think this approach helps on a variety of fronts:

• SEO for docs and questions gets easier - searching for "Denali Blackburn" is likely to be more effective than "Denali 2.3"
• Easier marketing efforts - release names lend themselves to branding (i.e. Android Oreo).

Thoughts?

[seawatts]

❤️ the android reference! I like the total idea. I think not really having this with Ember might have hurt them a little, which is a bummer.

[knownasilya]

We should suggest this for Ember 👍

[acorncom]

Yep 👍, I think it's a good idea, as we discussed in person. Could make guides / api urls a tad harder (do you go with release names or with version numbers in version switchers and urls for instance?) but well worth dealing with those gotchas 😀

[davewasmer]

@acorncom good points, definitely need to consider those. My gut would say, ideally, the docs version picker is version number based, but named versions are noted in the dropdown, i.e.:

v1.1.0
v1.2.3
v1.3.1 (Blackburn)
v1.4.2

And that named urls would redirect to specific version numbers, i.e.:

/docs/blackburn/guides/application/action

would redirect to

/docs/v1.3.1/guides/application/action