I just came across a bunch of edits tagging questions with . I approved them as the edits seemed to match the tag wiki:


Ember API has changed over time. This tag is for all the questions that are no longer valid due to deprecated code. This makes the relevant questions more visible.


All the questions that no longer apply to the current post ember-1.0 release should be tagged ember-invalid

However I then wondered if it wouldn't be better to have a specific version tag like ember-0.9 (note, that's just an example, as I have no idea what versions ember actually has) rather than a generic one that would keep rolling forward.

There are plenty of answers on Meta that suggest that a generic "deprecated" or "outdated-version" tag isn't ok as it is a meta-tag (e.g. https://meta.stackexchange.com/a/146385/132930), this is sort of a hybrid as it only relates to this particular subject.

Should this tag be replaced with something more specific that isn't time-sensitive?


5 Answers 5


If I understand Trek Glowacki's answer correctly, it seems that this tag was being applied to the questions that:

  • were about the unstable and currently unsupported 0.x beta versions of ember.js, and

  • specifically ask about API features or implementation details that were removed prior to the release of the stable ember.js 1.x API.

If so, I believe a reasonable way forward would be tag them with a version-specific tag, such as or . This will allow the questions to be kept on Stack Overflow for historical interest (if they're otherwise on topic), while clearly differentiating them from the ember.js 1.x questions.

While version-specific tags are generally discouraged on Stack Overflow, they do have valid uses, and I believe this would be one of them. Specifically, to quote Jeff Atwood:

"I would only use version tags when the question content is irrevocably tied to a specific version of something and can never be relevant to earlier versions or later versions."

If I understand the explanations given by the ember.js developers in the other answers correctly, this seems to be exactly the situation here: these question are irrevocably tied to the 0.x beta versions of ember.js, and are not in any way relevant to any version since 1.0.

(Since all the 0.x versions are now unsupported, I see no need to more finely differentiate between them; a single tag for all of them ought to be enough.)

Ps. If you feel it's necessary, leaving a comment stating that a specific question or answer is not applicable to ember.js versions since 1.0 (or whatever) is perfectly acceptable. Editing posts to add a more prominent notice to the same effect, as suggested by Charles, is somewhat more controversial, but might be acceptable in some cases (e.g. if the accepted answer to a valid question no longer works in modern versions).

Alternatively, where practical, you could also consider simply editing obsolete answers to fix them or to add a working solution. There's a fine and sometimes controversial line here between fixing a broken answer and putting words into someone else's mouth, but, generally, appending something like:

"Edit: The solution described above no longer works in ember.js 1.0 or later. For modern versions of ember.js, [use the following code / see the answers below] instead."

would probably be considered reasonable.


Nope. It's a meta tag. Commence burnination.


The tag is a meta tag. If the name itself doesn't already indicate that, its very purpose does. As was stated in a blog post its very purpose is to identify a list of questions to be possibly even deleted.

So yeah, a meta tag, not a valid tag, so it has no business being around.

As for the issue of deletion, that's simply a no no. It shouldn't happen and is not how the site works. One example given in the blog post is the following:

An example of a question that should be deleted is this question related to Ember.Button. Ember.Button has long been deprecated and removed.

That doesn't mean that all such content needs to be removed from Stack overflow. At most it indicates a versioning issue. As Servy suggested in a comment, a pre-release related tag could possibly work for that. Use a tag to identify pre-release questions, and perhaps add relevant information on its unsupported/deprecated nature in the tag wiki.

But applying a meta tag meant to identify posts to possibly delete is not the way.

  • So what should we do? Wait a couple of days for the Ember community to find a better solution, otherwise mass rename the tag to ember-pre-release? Feb 17, 2014 at 22:34
  • 3
    Let's wait and see if we get some input from them first @GaneshSittampalam. They are the concerned party, they want a solution, so let them provide some input. As far as I'm concerned (given my unfamiliarity with the full situation) we simply remove the current "invalid" tag and let that be it. But perhaps they'll tell us that a rename to pre-release would work just fine. Let's see.
    – Bart
    Feb 17, 2014 at 22:36
  • It seems like someone has deleted it now anyway. If the history of the questions it was applied to is wanted, it's mostly in Willem's activity history: stackoverflow.com/users/1474739/willem-de-wit?tab=activity Feb 18, 2014 at 6:46
  • Yeah, it seems that Bill went into them and revised them.
    – Bart
    Feb 18, 2014 at 6:53

Sorry for the hubub.

Let me explain the situation we're in and why we identified tagging as the first step in resolving the problem in a timely manner.

Ember.js has a fairly long history as browser application frameworks go: we started out as a beta fork of SprouteCore 2.0 in 2011, which brought along certain packages from SproutCore, while entirely replacing others. In 2012 we fully split from SprouteCore and rebranded as Ember.js.

After the split we had a 16 month beta period. And not "beta" like some software has where the public API and feature set is mostly stable, but they developers just want to reserve the right to break your app with an update.

We take versions numbers seriously: 1.0 means no backwards breaking changes so we hesitated to release a 1.0 until we felt comfortable supporting the public API as-is for the foreseeable future.

It's why we get tweets like this: https://twitter.com/phil_renaud/status/435571253777539072

The beta period was a time to experiment, very rapidly, with APIs. Ember.js is composed of many smaller packages. Some of the packages have maintained a high amount of stability for long periods of time (the API of the core, low-level bits are mostly unchanged from 2011).

Others packages have rapidly shifted while we hunted for better solutions, listened to feedback, and adjusted.

We've always been very public about this process, so people evaluating Ember.js over the last few years were rarely surprised when we'd do something like totally change a large, high level API (like our router) three times in as many months (disappointed, sure, but never surprised).

During this whole process, Stack Overflow was a valuable destination for connecting people trying to make sense of Ember and people who had developed expertise and were willing to give back to the community.

In August 2012 we released Ember.js 1.0. In 1.0 some packages were very similar to their 2011 ancestors and others were so wildly different that they really should be considered entirely new pieces of software, totally unrelated to older packages.

While this distinction is fine for developers of Ember.js, it's a unnecessarily nuanced for developers using Ember.js. To them, Ember is Ember is Ember.

This is especially true for developers new to the framework. As the API solidified and we approached 1.0 we saw increased adoption. This was mirrored by increased complaints about the poor quality of Ember.js questions and answers on Stack Overflow.

To a new Ember.js developer Stack Overflow appears to be mostly "best" answers that are awful. Not just "not helpful", but downright misleading and time wasters. It's why we see tweets like this:


We want Stack Overflow to be useful to the Ember.js community again.

In general, Ember.js posts fall into three categories:

  1. Questions that are no longer valid. These are about parts of the framework that were short-lived and have been gone for a long time.

    I would argue that true beta software is significantly different than older release versions of software. Beta software is never intended to live long, it changes rapidly (sometimes between single commits), knowingly doesn't represent the best or final pattern, and has a low likelihood of being still being deployed in the wild.

    Contrast with, say, a question about older versions of Rails' router. Each version of the Rails router has had a relatively long-lived public API and there is a decent chance you work on or will inherit a project using this software and historical answers are invaluable.

    Stack Overflow doesn't really have a semantic to express the difference. I suppose Too Localized (in the essence of "too localized in time") used to be the closest. There's no quick way to know what version a historical question refers to, so tagging a specific version isn't helpful.

    Even if we did version tags (something like ember.js-prerelease), that ignores the fact that Stack Overflow lives in a larger ecosystem. Googling "ember and buttons stackoverflow" leads you here Ember.js how to use Em.Button

    The accepted answer was right but is now so wrong as to essentially be nonsense or about totally unrelated software. Trying this code will not work. Trying this pattern might work, but it is so bad we purposely abandoned it. This is not obviously communicated to the reader. Questions like this should just be closed, but no close reason matches this situation.

  2. Questions that are valid, whose best answer is now misleading or incorrect.

    In the past we've tried, and mostly failed, to remedy this by supplying better answers based on the final answer we arrived at. Time is against us. Answers that used to be good but are now poison retain their high vote counts. Existing community members tend to not visit older answered questions, new developers tend to arrive at them via search and contact us with their frustration.

  3. Questions that are valid, whose best answer is still valid. No action needed here.

    Here is our problem: determining which of the above numbers describes a question sometimes requires a higher level of expertise. While I'd like to personally address each of 4,000 or so ember.js/ember-data question, it's just not possible to do in a timely matter. The situation is pretty dire and has been for some time. We need some solution to triage the mess and having our community help identify bad questions or questions with bad answers speeds this process. Stack Overflow doesn't offer any specific tools for this process, but tagging is the closest, which is why we started using it.

    We'd hoped the natural organic process of Stack Overflow would eventually address these problems, but it's been five months and the problem hasn't improved.

    So, the ember-invalid tag is not intended to be permanent. It's only there to let us distribute the work of identifying questions that most need our attention. Once we've gotten that list, we're still honestly at a loss for what to do.

    None of the close reasons match our situation, but it's irresponsible to leave these questions in their current state and not at least find some way to communicate that a question or answer was so localized to a very brief, unstable moment of time that what you're seeing should be highly suspect.

Replying to some comments above:

He also created that tag, and is the only one editing it on

I created the tag, but only used it once. Other members of our community are tagging.

a specific version tag like ember-0.9

We tried this with the ember-old-router tag. It did not remove any confusion. Unless a questioner mentions which version he's using, it's hard to even tell which version he had.

"Apply some form of cleanup" hopefully would be new answers to the questions explaining how the new, better ember would solve their problems

That's the hope for questions that are still valid. Questions like "How do I accomplish X in Ember" are ideal for this. "How do I use function Y?" when Y was in the API for a month has no meaningful new answer. It's just noise. The metatag is the best solution we've found for organizing the process of highlighting areas to improve.

They're certainly not "invalid", but if they're acting on an entirely different (version of) a platform that can warrant a tag.

Imagine, for a moment, we renamed Ember to Foo when we released 1.0. Would it be proper to find all the old ember.js tags and re-tag them with Foo, even if the question or best answer no longer applied to Foo? Or, imagine if there was no ember.js tag, just tags for each of the libraries that comprised Ember. If we replaced a library with a similar one with a different name, would we go update the old questions with tags pointing to the new software? This is exactly the situation we're in, with similar confusing effects.

  • 2
    One point: wouldn't it be better to make a list of all of these questions, and not tag them with a meta-tag? And also, don't close those questions. Just no. :) Lastly, can't you reanswer some of those questions with working code for the new version?
    – hichris123
    Feb 18, 2014 at 2:12
  • 3
    Please consider using semver for your individual API components. This way, when you need to completely break an API in the name of progress, you have clear and obvious way of indicating this in a way that is developer friendly, search friendly, and SO tag friendly. Also, it is not entirely inappropriate to edit in "hey, this question was valid in the past but mentions concepts that are totally bogus now" preambles into popular but misguided questions.
    – Charles
    Feb 18, 2014 at 6:02
  • 1
    This answer is essentially a justification of why it's important for Ember to have a meta-tag. The problem is that StackOverflow has a long history of not wanting meta-tags that is seen as important for StackOverflow as a whole, and it looks unlikely that you could overturn that. So what alternatives are there that would keep both sides happy? Would the ember-pre-release tag that's been suggested be suitable? Feb 18, 2014 at 6:44
  • ember-pre-release seems to setting you up for another nightmare when you have a pre release for ember 2.0. What did you call this version, ember 0.x, or ember-1.0-prerelease? Feb 18, 2014 at 9:38
  • What I would do is follow this approach: (1) question and answer remain valid : do nothing. (2) question makes sense but answers are now wrong : add comment on/in answers stating that they are for prerelease and add a correct answer. (3) Question makes no sense now : tag as ember-1.0-prerelease or similar Feb 18, 2014 at 9:41
  • 1
    All great comments. If you read above you'll see they were all specifically address. Several were tried and did not work. Feb 18, 2014 at 12:51
  • 1
    SemVering each module sounds great in hindsight but it doesn't addresss the current problem.Moving forward all parts of Ember are compatible back to 1.0 anyway Feb 18, 2014 at 12:53
  • 3
    It's worth emphasising that the onus is on you to find something that works for you and fits with the S.O. rules - as things stand a moderator has already deleted the ember-invalid tag in any case. Would using ember-1.0-prerelease as suggested be an acceptable substitute? Feb 18, 2014 at 13:10
  • 1
    "Would using ember-1.0-prerelease as suggested be an acceptable substitute?" Nope. It does not address all three question types, as I mentioned above as our reason for trying tags. Feb 18, 2014 at 13:16
  • 1
    "It's worth emphasising that the onus is on you". I'd say if you care about the quality of questions and answers as a whole on Stack Overflow the onus is on all of us. We've come to you with a problem and nobody, yet, has suggested anything other than what we've already tried and failed with. Feb 18, 2014 at 13:19
  • 1
    At this point the best suggestion I've heard is to make the list externally and organize a concentrated downvoting(bad questions)/upvoting (better answers). But, this is detrimental to the users who asked previously-valid questions. Why should they lose rep because time moved on? Feb 18, 2014 at 13:27
  • 2
    "It does not address all three question types" ... it does address the first one. For the second type, add a new answer, clearly stating that other answers are outdated. And for the third no action is needed.
    – Bart
    Feb 18, 2014 at 14:28
  • 1
    "it does address the first one" assuming people know to check the tags. This does not appear to be the case from the feedback we get. Just tagging has not resolved similar problems for us in the past. I'm not sure how many more times I need to say this before people believe we have tried the acceptable way in the past and it has not relived the problem. Feb 18, 2014 at 15:11
  • 2
    Essentially, we need good, responsible way to indicate in a very visible way: This question/answer is no longer correct. It was at a small, discreet moment of time, but no longer reflects reality. Previously, we tried doing that with ember-old-router and it did not work. Everyone, please stop suggesting version tagging: It may work generally, but for beta software we have tried it, it did not work. If you think it will work better this time, please say why. Version tagging may work in conjunction with another solution, so please keep brainstorming. Alone, however, it did not help. Feb 18, 2014 at 15:21
  • 5
    You have however skipped over Charles' comment. In addition to appropriate version tagging, he said it is not entirely inappropriate to edit in "hey, this question was valid in the past but mentions concepts that are totally bogus now" preambles into popular but misguided questions.. In what cases, and in what exact format is something that could perhaps be discussed.
    – Bart
    Feb 18, 2014 at 15:43

The core team just announced that they want do remove the old question which no longer apply because of the API changes Ember had in the past. It's hard for new users to distinguish between questions that are relevent for them and questions that are not.

The reasons to remove the questions:

  • pre-release software is often undocumented and unfinished, leading people to use Stack Overflow as a place to find answers at higher rates than for relased software
  • people should not continue using pre-release software for long after an official release, so there is little value in having those answers around for future reference
  • good questions might have wildly different answers before and after a 1.0 release but there's no way for a new user to know
  • some questions themselves will no longer make sense as features are added or removed

We're working to do some form of cleanup for questions like these. The first step is to compile a list of ones the community feels should be removed. With that list we'll apply some form of cleanup

More information about this in the blog post

  • 11
    "The core team just announced that they want do remove the old question which no longer apply because of the API changes Ember had in the past." ... ehm, no. They need a serious lesson about how SO works. And that is not it.
    – Bart
    Feb 17, 2014 at 21:40
  • 6
    The problem is that StackOverflow gets to decide the policy for questions on StackOverflow, not the Ember core team. Feb 17, 2014 at 21:40
  • 8
    If they're questions that apply to the pre-release then tag then as "ember-pre-release" or something that indicates they're before the formal release. They're certainly not "invalid", but if they're acting on an entirely different (version of) a platform that can warrant a tag.
    – Servy
    Feb 17, 2014 at 21:41
  • 3
    I'm not sure "ember-invalid" even gets the message you're trying to give across. Sounds more like a product name: "Announcing the new error checking software from ember: it's ember-invalid! " Feb 17, 2014 at 21:44
  • 2
    "Apply some form of cleanup" hopefully would be new answers to the questions explaining how the new, better ember would solve their problems
    – curtisk
    Feb 17, 2014 at 21:50
  • 3
    Yeah, like @Servy says, this seems to be better solved by "versioning", rather than tagging to delete. Deleting IMO shouldn't happen here anyway.
    – Bart
    Feb 17, 2014 at 21:54
  • 1
    Maybe only half-related, but still: If you decide to re-tag with valid tags, PLEASE let users do the work who can edit without a need to review. The review-queue was awful last (UTC-)night, with every retag you did in there. You DO realisze that at least 3 people have to review every edit you made, so you provided totally unnnecessary work for 3-4 people? (3 for each review, plus one to revert it in the end for those who got approved...) Feb 18, 2014 at 11:07
  • On the other hand without the need for review, this probably wouldn't have been caught so soon. Feb 18, 2014 at 13:23

Not the answer you're looking for? Browse other questions tagged .