JavaScript 2015?
I think JavaScript 6 will only make things more confusing (remember JavaScript 1.7, 1.8, etc. in Mozilla?).
More and more people learn what ECMAScript is. ES6 / ECMAScript 6 seems the most appropriate (and least surprising) name.
"The new JavaScript: ECMAScript 6"?
The spec is no longer called ES6. The marketing hasn’t really begun to educate the community about this yet, but the spec is called ES 2015.
As for your concern about 2015 seeming old in 2016: good. In 2016, we’ll be publishing ES 2016, and ES 2015 will be missing a lot(*) of stuff that ES 2016 has!
(*) hopefully.
Honestly though, to the largest portion of JavaScript developers, the least
surprising name would be JavaScript 2.0
That term is kind of poisoned it seems:
The spec is no longer called ES6. The marketing hasn’t really begun to educate the community about this yet, but the spec is called ES 2015.
OK, good to know. Does it make sense to normally refer to it as “JavaScript 2015”, then?
As for your concern about 2015 seeming old in 2016: good. In 2016, we’ll be publishing ES 2016, and ES 2015 will be missing a lot* of stuff that ES 2016 has!
Even ignoring books, I don’t share that attitude: for programming languages, a slower pace is good. It took people a long time to get used to ES5 and ES 2015 will have many more new features. It will take time to:
- Completely implement ES 2015
- Write proper material
- Educate people
- Establish modules (I’m seeing browser APIs based on promises, but none that are based on modules)
Axel
From: Axel Rauschmayer [mailto:axel at rauschma.de]
OK, good to know. Does it make sense to normally refer to it as “JavaScript 2015”, then?
I don't really think so, but I don't have a storng opinion.
Even ignoring books, I don’t share that attitude: for programming languages, a slower pace is good.
Well, I'm sorry* the committee plans to disappoint you then :).
* not actually sorry.
- Establish modules (I’m seeing browser APIs based on promises, but none that are based on modules)
This is just further reflection of the idea that spec version numbers are fictional and what matters is implementation progress. Promises are established because they've been implemented for a long time now. Modules aren't even close to being implemented anywhere. Saying they're both part of the same Word document is a true, but useless, statement.
There's a lot of projects, articles and materials out there using the "ES6" nomenclature. I don't think changing the name right now, close to the final release, and when people are already familiarized with the name is good approach. What is the point? Using the year in the version name remind me Windows.
FWIW, here's the rule of thumb that I tend to use:
- When referring to the language in general, it's Javascript or JS.
- When referring to a specific version of the language, it's ESx (e.g. ES5, ES6, ES7).
- When referring to the specification itself (e.g. in proposals), it's ECMAScript.
Anyone want to venture a guess on what percentage of JavaScript developers (and then, from there, developers who use other languages) have heard of ES or ECMAScript?
I now version does not matter but implementation and features matter, why then you dropped the "Harmony" name? It was using for a while, then ES6 was using for a while, now you wants new name. Sounds weird. Argument about features does not work.
agreed and not only, it took years before various engines fully implemented ES5 so saying years later that an engine is fully compliant with a year in the past feels so wrong !!!
Why is that? Where is the thread that explains this decision?
I mean ... how should I call my browser that is not 100% compliant with HTML5, a fully compliant HTML 1997 browser ?
Thanks for any sort of clarification
"Harmony" refers to the whole post-ES4 consensus-based arc of specs from ES5 (neé 3.1) onward into the future, until "done" ;-). See
ECMAScript Harmony never referred to a specific edition of ECMA-262, nor could it. The "Harmony" name is used in nearby sub-fields of programming languages and software, e.g., the open source Java libraries developed under Apache auspices.
FWIW, ES6 is a known thing, in view of sites such as
kangax.github.io/compat-table/es6
(which goes to "7" ;-).
Still, we can probably educate people and spread the word that ES6 = ECMAScript 2015, ES7 = ECMAScript 2016, etc. All under the "Harmony" umbrella, I trust.
Andrea Giammarchi wrote:
agreed and not only, it took years before various engines fully implemented ES5 so saying years later that an engine is fully compliant with a year in the past feels so wrong !!!
Why is that? Where is the thread that explains this decision?
I mean ... how should I call my browser that is not 100% compliant with HTML5, a fully compliant HTML 1997 browser ?
Of course this question arose with respect to HTML5, which was nowhere near "done" (is it yet?) before marketeers at browser vendors started touting compatibility and various players hyped the orange shield. (And then Hixie said it was a living spec, version-free. :-P)
The reason to label editions or releases is not to give marketeers some brand suffix with which to tout or hype. It's to organize a series of reasonably debugged specs that implementors have vetted and (partly or mostly) implemented.
I agree it would be best if (partly or mostly) were "fully", but that's not practical with big "catch-up" specs. With "rapid-er release" annual editions, it should be a goal, IMNSHO. That's the promised land we seek: implementor- and developer-tested draft matter that "sticks" and then gets the de-jure stamp of approval.
Harmony = everything after ES4’s disharmony. ES5 is part of Harmony, as is ES 2015, as is ES 2016, and everything further. It’s not dropped.
Brendan Eich wrote:
The reason to label editions or releases is not to give marketeers some brand suffix with which to tout or hype. It's to organize a series of reasonably debugged specs that implementors have vetted and (partly or mostly) implemented.
I agree it would be best if (partly or mostly) were "fully", but that's not practical with big "catch-up" specs. With "rapid-er release" annual editions, it should be a goal, IMNSHO. That's the promised land we seek: implementor- and developer-tested draft matter that "sticks" and then gets the de-jure stamp of approval.
The WHATWG "living spec" alternative eschews any series of spec snapshots, favoring just a bleeding edge that implementors constantly chase.
This ideal has real-world issues! Perhaps Boris Zbarsky or someone else will comment on them. I'm out of time and not motivated, since for JS, we will promulgate an evolving series of spec editions, from ES6 = ES2015 onward at an annual cadence.
Part of the benefit of the cadence, which resonates with faster software rapid-release schedules such as Chrome's and then Firefox's: you avoid schedule chicken by waving off anything unready till the next "train". There's always another one coming, and no way to delay, so it doesn't pay to pretend to be more "done" than you really are.
The rapid-release approach still requires skill and art to get right and avoid missing a train (always a set-back and embarrassment, as in real life).
I really don't understand ...
Draft ECMA-262 6th Edition people.mozilla.org/~jorendorff/es6-draft.html
ECMAScript 6 support in Mozilla developer.mozilla.org/en-US/docs/Web/JavaScript/New_in_JavaScript/ECMAScript_6_support_in_Mozilla
ES6 Rocks es6rocks.com
Books already published, years of blog-posts all over the internet educating developers about ES6 features. A clear deadline in terms of features instead of year since by the end of 2015 I am pretty sure no engine will be fully spec-compliant with the spec.
What is this new "back to year-versioning" approach?
Why suddenly we need a full new release each year when it took 15 years to have full ES3 support from all vendors?
This feels like Adobe and the AS1 to AS3 era, the one that lost most developers due inability to catch up with anything and confusion across just specs.
And that was a single "vendor" proposing new features for its language, I cannot imagine where this is going.
/rant
Best
Andrea Giammarchi wrote:
I really don't understand ...
I'm pretty sure you do understand -- you just don't like it.
The annual cycle may fail, but that would be "bad". If it works out, we could still continue with ES6, 7, 8, etc.
I'm leery of revolutionary fanaticism of the kind that led the French revolutionaries to invent new month names. Perhaps we're overreaching by declaring ES2015 before we've even wrapped up ES6, never mind implemented all of it in top browsers! You could be calling b.s. on this, please tell me if I'm "warm".
Anyway, I agree "ES6" is out there. I cited kangax.github.io, and of course you're right, there are other sites and tutorials. The ES5/6/... pattern won't go away over night, no matter what bloody revolutionaries try to enact :-|.
This should keep everyone from charging ahead with renaming right now. We need to socialize the annuals idea more, and actually hit the schedule. At that point we will have ES6 = ES2015, ES7 = (probably) 2016, etc. -- twice the number of names to keep straight.
I do the same as Kevin.
JavaScript X === EcmaScript Y :- X === Y + 2009 && Y >= 6;
Two different issues:
- I agree that renaming ES.next this late will be difficult
- The smaller incremental releases have been planned for a while [1] and make sense: only if something is mostly done in most browsers does it become part of the standard. That is, releases are driven by features not the other way around. How often is debatable, but small and incremental is good.
[1] tc39/ecma262, tc39/ecma262 (esp. link “this process document”)
2015-01-23 2:02 GMT+02:00 Brendan Eich <brendan at mozilla.org>:
"Harmony" refers to the whole post-ES4 consensus-based arc of specs from ES5 (neé 3.1) onward into the future, until "done" ;-). See
ECMAScript Harmony never referred to a specific edition of ECMA-262, nor could it. The "Harmony" name is used in nearby sub-fields of programming languages and software, e.g., the open source Java libraries developed under Apache auspices.
Good to know, thank you. My commend was kinda raged.
But I still think it is weird thing to change name right now. Also, all those details about Harmony are not (or were) well known, because at a time of popularity of "Harmony" keyword all referred to it as next JavaScript/ECMAScript. That was exactly about features, not versions. Also, it seems that right now all still refers to features -- browsers implement them one by one, people talks about parts of specs not about whole thing. Yes, it sounds reasonable to move away from versions. But for now ES6 is already promoted, may be not specially but it is. For me it seems like stick up to Harmony would be better idea.
Or let's go to Microsoft way and call it "ECMAScript One" (joke).
I've read after sending last email the rationale but I am still not sure "continuous specs integration" should be related with the year.
I particularly don't like the idea that things could be dropped or rushed last minute just because the new years eve is coming ... this feel like those stories with tight deadlines where management could easily fail due over-expectations on all possible 3rd parts alignment ( you know, like those 12 different JS engines out there .... + spartans )
I do like the idea of having more frequent rolling releases, but yet I don't know why year-naming would be the choice.
Anyway, please consider keeping ES6 exactly ES6, we will have time to align the ESX where X = previous ESX +2009 concept.
to Doctor Alex, at this point I think you should really stick with ES6 or avoid the ES at all and use JS 2015
Your book though, won't be so interesting in few months, users also pay a lot of extra and unnecessary attention to a year in a name ... things will feel outdated before will be even implemented by some vendor.
Weird choice, not my cup of tea for sure.
Best
Andrea Giammarchi wrote:
I particularly don't like the idea that things could be dropped or rushed last minute just because the new years eve is coming ... this feel like those stories with tight deadlines where management could easily fail due over-expectations on all possible 3rd parts alignment ( you know, like those 12 different JS engines out there .... + spartans )
No last minute slips -- that's a schedule-chicken outcome (where the cars do not collide but one veers and drives off a cliff!).
The new stuff has to board its "release train" or its champions and fans will be sad, and perhaps take a credibility hit. This doesn't mean larger work must be broken down into too many pieces, but that is a risk.
Larger work that can track across multiple years is always risky -- in my experience it very often aims for a target near Alpha Centauri at sublight speed, when the real action was over at Tau Ceti due to an FTL breakthrough, but no one knew at first that (a) FTL was possible; or (b) the Centauri systems were uninhabitable. If you get what I mean ;-).
(Spartan uses Chakra, last I heard.)
Mature projects can do rapid-er release more easily than young ones, for sure. I recall 4.2BSD Unix, then 4.3, and a bit of 4.4.
I do like the idea of having more frequent rolling releases, but yet I don't know why year-naming would be the choice.
Does the name matter? You seemed to be objecting on more substantive grounds. Don't back off to mere quibbling about labels!
Anyway, please consider keeping ES6 exactly ES6, we will have time to align the ESX where X = previous ESX +2009 concept.
to Doctor Alex, at this point I think you should really stick with ES6 or avoid the ES at all and use JS 2015
This reminds me: Axel (not Alex) cannot recommend "JavaScript 2015" to anything near the Ecma standard, because trademark. :-/
Apologies, Dr. Axel indeed. So if I understood correctly, a title cannot contain ES6 or ECMAScript name in it at all? Or not even the JavaScript bit? More confusion :D
Can we leave ES6 to ES6 because it's already here and call ES7 -- ES2016? Since ES7 not here yet and there are not much mentions of it.
2015-01-23 2:39 GMT+02:00 Brendan Eich <brendan at mozilla.org>:
This reminds me: Axel (not Alex) cannot recommend "JavaScript 2015" to anything near the Ecma standard, because trademark. :-/
Ah, good point. It’d be lovely if whoever owns the trademark now (Oracle?) could donate it to the community. Or the community buys it via crowd-funded money.
so more book authors concerned with the year-name choice: twitter.com/angustweets/status/558425590928113664
now I am curious to know how come all books out there have JavaScript in the title but AFAIK Oracle is not even mentioned ... is Oracle being very permissive or a book title should really not contain the JavaScript bit ?
Thanks again, I am writing one these days and no idea where to find these info.
Best
That would be my preferred solution: the name affects book covers, domains, content, etc. = a significant amount of time and money.
Even worse than renaming ES6 now would be renaming it later, though.
Name names. Who's idea was this? :)
btw, just to answer your picks, I think this ML and ECMA in general has done a very good job last few years.
I've heard the "delivery, delivery, delivery" story before and I haven't seen a single case where that translated into more quality as outcome.
The label behind the year-name convention is not convenient for anyone:
- books will look either older than they actually are or crystal-ball oriented (at least for less familiar users eyes)
- for years we'll have to explain how to convert an ES version to the year and why at the beginning this was not a year-based thing
- some year might be the alignment year where only one major feature goes out but it goes out the right way ... how'd you explain that ES 20XX ?
- you mentioned ES 3.1 instead of ES5 ... that's just good ... if we need intermediate changes why not, we have officially a 5.1 too I don't remember anyone complaining there
Having major release forced on year basis feels far away from agile or continuous integration principles, so yeah: year-name to define deadlines is bad because of the year-label thing, and because of the concept behind.
We have numerous sites showing the current implementation status of current specs or even future one ... it's already difficult to understand who supports what, having "must release this year" versions out there will make the scene look like a bingo.
This is probably just me playing the crystal-ball rant part but what bothers me the most is that until today I've never heard about this new trend/idea/decision.
I don't think I've missed notes or threads, if so, please point them out, if not, please explain where these decisions come from if that's possible. Maybe me or others could follow that channel too? Or maybe not, but it would be nice to eventually know it.
Best
Andrea Giammarchi wrote:
Apologies, Dr. Axel indeed. So if I understood correctly, a title cannot contain ES6 or ECMAScript name in it at all? Or not even the JavaScript bit? More confusion :D
Don't exaggerate. I clearly addressed Axel and only with respect to "JavaScript 2015", as cited below.
/be
On Fri, Jan 23, 2015 at 12:39 AM, Brendan Eich <brendan at mozilla.org <mailto:brendan at mozilla.org>> wrote: ...
I wouldn't hold my breath. Sun was not ever in the mood, even when I checked while at Mozilla just before the Oracle acquisition closed. Also, "the community" cannot own a trademark.
Trademarks must be defended, or you lose them. This arguably has happened to JavaScript. Perhaps the best course is to find out (the hard way) whether this is so.
The annuals idea was agreeable to TC39ers a recent meetings. Whether and how we cut over was not decided, in my view.
Rushing to the new revolutionary calendar would be a mistake. We (TC39) need to cash checks we've written, and not with our body :-P.
I believe the cutover was decided in the September 25 meeting.
Domenic Denicola wrote:
I believe the cutover was decided in the September 25 meeting.
I must have missed it if so -- do the notes record it?
As Andreas Rossberg points out, ES6 will take years to be fully implemented. The more we speculate (lay bets), the bigger our potential losses.
At this point, I personally want to see ES6 more spec'ed and implemented (not saying it's not spec'ed fully, the lag is on the implementation side -- but that can feed back on the spec).
Anything further, even a "simple" (hah!) thing like naming, seems somewhere between "good intentions to try out on the wider community" and "hubris". Let's avoid the latter. I think we're soaking in the former.
Whenever you mention revolutionary calendar I'm reminded of subsidized time in Infinite Jest. "ES Year of Dairy Products from the American Heartland" anyone? :)
On Jan 22, 2015, at 5:40 PM, Brendan Eich wrote:
Domenic Denicola wrote:
I believe the cutover was decided in the September 25 meeting.
I must have missed it if so -- do the notes record it?
tc39/tc39-notes/blob/master/es6/2014-09/sept-25.md#conclusionresolution-1
bassed upon that I confirmed with Istvan that Ecma was ok with a document title change
However, I delayed actually change the cover page until the first draft release in 2015
That change was announced in the release notes: harmony:specification_drafts#january_15_2015_draft_rev_31
And highly visible to anybody who looks at the front cover: harmony:working_draft_ecma-262_edition_6_01-15-15.pdf
On 1/22/15, Brendan Eich <brendan at mozilla.org> wrote:
Andrea Giammarchi wrote:
agreed and not only, it took years before various engines fully implemented ES5 so saying years later that an engine is fully compliant with a year in the past feels so wrong !!!
Why is that? Where is the thread that explains this decision?
I mean ... how should I call my browser that is not 100% compliant with HTML5, a fully compliant HTML 1997 browser ?
Of course this question arose with respect to HTML5, which was nowhere near "done" (is it yet?) before marketeers at browser vendors started touting compatibility and various players hyped the orange shield. (And then Hixie said it was a living spec, version-free. :-P)
HTML5 isn't going to be done. I wrote, "extensible design doesn't have a due date", someone else coined "living standard", and that sealed it in.
EcmaScript differs from HTML5 obviously in that it defines the syntax, including new syntax features like spread, modes (strict and non-strict), and internal specification methods like [[ToPrimitive]] new internal methods like [[NeedsSuper]].
Syntax features are more complex than new built-ins (or any new host objects of HTML5) because they affect the language itself and all of its dependencies, internal and external. Language modes increase this complexity.
Modularity can make "when is it going to be done" less of an issue. I don't see how modules could be used for new syntax features (they possibly could be; I just don't see how).
But speaking of the orange shield, what about a sticker for HTML4 with "It works" as a tagline?
Allen Wirfs-Brock wrote:
And highly visible to anybody who looks at the front cover: harmony:working_draft_ecma-262_edition_6_01-15-15.pdf, harmony:working_draft_ecma-262_edition_6_01-15-15.pdf
Serves me right for looking only at the HTML!
Not for Allen, who I am pretty sure agrees:
This seems "just fine", not a problem. Yet at least for a while, possibly longer than some TC39ers think, people will still say "ES6". I find Andrea's WTF to be overdone, overstated -- but we shall find out. Even TC39 can make changes based on wider feedback, after it has made a decision.
The idea of a community-approved name or naming scheme brings to mind that Axel wished for a "community-managed" trademark. Be careful what you wish for. The Ecma TC39 renaming process (like just about any other TC39 decision process) was not community-driven, with a lengthy propose/listen/dispose cycle and some kind of "open governance" (however defined).
Rather, we're still doing consensus among a mix of pay-to-play and not-for-profit standard body members, where members have to build trust among developers and work in Harmony, at least in the modern post-ES4 era. Renaming angst, which could become an issue or just blow up for some reason we can't foresee, is just one issue to address for the same of developer trust and harmony.
Garrett Smith wrote:
Modularity can make "when is it going to be done" less of an issue. I don't see how modules could be used for new syntax features (they possibly could be; I just don't see how).
This is actually a goal that can be achieved (from all similar past research, e.g. Racket) via hygienic macros and a module system with sufficient static semantics. See sweetjs.org.
But speaking of the orange shield, what about a sticker for HTML4 with "It works" as a tagline?
I like the middle one below! :
Andrea Giammarchi wrote:
I've heard the "delivery, delivery, delivery" story before and I haven't seen a single case where that translated into more quality as outcome.
You make it sound like quantity goes up, or at least exceeds what can be "QA'ed" by implementors and developers before being standardized. That too would be a failure. If ES2016 is very slender, so be it. Perhaps that will cost credibility, but it's better than creating another multi-year catch-up situation, as we had in ES5 and then ES6.
On Jan 22, 2015 7:17 PM, Brendan Eich <brendan at mozilla.org> wrote:
Allen Wirfs-Brock wrote:
Serves me right for looking only at the HTML!
And the html is still one rev behind so you are missing all of the constructor redo that is in rev31
Send it with the right metadata...
On Thu Jan 22 2015 at 9:58:24 PM Allen Wirfs-Brock <allen at wirfs-brock.com>
wrote:
On Jan 22, 2015, at 5:40 PM, Brendan Eich wrote:
Domenic Denicola wrote:
I believe the cutover was decided in the September 25 meeting.
I must have missed it if so -- do the notes record it?
tc39/tc39-notes/blob/master/es6/2014-09/sept-25.md#conclusionresolution-1
bassed upon that I confirmed with Istvan that Ecma was ok with a document title change
However, I delayed actually change the cover page until the first draft release in 2015
That change was announced in the release notes: harmony:specification_drafts#january_15_2015_draft_rev_31
Then it makes sense to also align Ecma-402 (since it wants to align with Ecma-262) and the 2nd edition should just be Ecma-402 2015.
This seems "just fine", not a problem. Yet at least for a while, possibly longer than some TC39ers think, people will still say "ES6". I find Andrea's WTF to be overdone, overstated -- but we shall find out. Even TC39 can make changes based on wider feedback, after it has made a decision.
The idea of a community-approved name or naming scheme brings to mind that Axel wished for a "community-managed" trademark. Be careful what you wish for. The Ecma TC39 renaming process (like just about any other TC39 decision process) was not community-driven, with a lengthy propose/listen/dispose cycle and some kind of "open governance" (however defined).
Rather, we're still doing consensus among a mix of pay-to-play and not-for-profit standard body members, where members have to build trust among developers and work in Harmony, at least in the modern post-ES4 era. Renaming angst, which could become an issue or just blow up for some reason we can't foresee, is just one issue to address for the same of developer trust and harmony.
I have never advocated design or naming by popular vote!
I don’t care what ES7 is called, but I have to decide soon
From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of Axel Rauschmayer
I don’t care what ES7 is called, but I have to decide soon on what to put on the cover of an ES6 book and that cover will either be inspired by a 6 or by a 2015.
ES 2015 is the official name of the spec. Various people will probably still call it ES6 for a while. (I know it hasn't become automatic for me to type yet.) It might be hard for your readers to Google and find the official spec if you use "ES6", but they'll probably find other resources more readily, at least for now.
In general I think you're in trouble if you're trying to tie your book marketing to version numbers. Maybe naming a book after, say, C# 5 makes sense, since C# is essentially bundled with single-vendor Visual Studio releases and each version is implemented all at once. But even then, the old books I have on my bookshelf are named things like "C# in Depth" and "More Effective C#," and get edition updates as Microsoft spins out new versions. For the web, such a naming scheme makes even less sense. Features on the web are implemented piecemeal from draft specifications and/or living standards, and updated over time, and there is never a cross section of ES you can point to in real-world implementations and say "this is ES 2015".
Books purporting to cover "HTML5" or "CSS3" are a joke. The same is true for ES 2015, or ES 2016.
I bet hipsters will drop the "20" for a shorter name, ES15 ;)
I feel your pain Axel. I have been helping out with a lot of web boot camps lately teaching newcomers web technologies. Trying to explain all this is a real mess. Many developers I know that passively touch JS daily at work are unfamiliar, confused or frightened by the ES terminology still! At least with JS/ES you can explain clear iterations even if vendors haven't fully adopted. Living specs like HTML5 are almost impossible for newcomers to grasp, it's kinda sad.
Axel, I look forward to your book regardless of the title. It's refreshing to see someone care about educating people on proper nomenclature. Heck, it looks like this thread could be a chapter defining the mess that is web technologies :-)
Trying to understand the cadenced release process. In the past a Final Draft would be cut and allowed to bake for 12 months before an Official Approval by the Ecma General Assembly. Is that 12-month bake still going to be in place?
If this 12-month bake is still around, that would mean that the Final Draft for ES 2016 will need to be cut by June of this year, so that it can bake for 12 months and be ready by June 2016 for an Official Approval. This would mean that features not hardened enough by June 2015 will not make it into ES 2016.
If this is not how it will work, could you share the expected process of future releases? I am very interested to hear how it will work.
BTW, great work! Label changes and all, I am very excited for this revision to be approved.
It may change, but based on the current cover, it looks like Booth ES6 and ECMAScript 2015 names could be right to use
The cover says:
- "Standard ECMA-262"
- "6th edition / Draft January 15, 2015"
- "ECMAScript 2015 Language Specification"
If an edition number is maintained, then anyone could either say ES6 or ES2015 and next anyone could say ES7 or ES2016
Now, I don't know if you intend to let "6th edition" in this form or switch it for "2015 edition" in some next publications
Until this draft publication people saw in first place the edition number (6) and then only the date, only people concerned by history looked at the date to check the technology context From now, they would first see the year number, then those who care could also see the edition number (if it remains this way)
It could be interesting and look agile to have a stable edition per year, but I'm pretty sure no one will care if a year is missing If you look at SQL editions names which are year based, many years are missing en.wikipedia.org/wiki/SQL#Standardization Note that people (me included) often mentioned SQL editions as SQL1 (86-87-89) vs SQL2 (92) vs SQL3 (99-2000), but this numbering finally disappeared
Regarding subversions for patches (as 3.1, 5.1), you may like it or not but switching to years does not forbid that Some 4D versions where called 2004.1, 2004.2, .... and some may have been published after 2004 but were still minor revisions of the 2004 version
About the language, name for wide communication, ECMAScript, and JavaScript are as of today often interchangeable (still depending of their usage context) People start to be more and more educated about ECMAScript, but most communications, hashtags, user groups, search keywords, ... are using still JavaScript or JS Many Books have JavaScript in their title even if it is trademarked by Oracle (and before by Sun) My company only used JS instead of JavaScript in a conference name because it is in first place a database company as Oracle is (but in a more modest size), so trademark may there have been source of issue
Alexandre
On Jan 23, 2015, at 3:58 AM, Allen Wirfs-Brock <allen at wirfs-brock.com<mailto:allen at wirfs-brock.com>> wrote:
On Jan 22, 2015, at 5:40 PM, Brendan Eich wrote:
Domenic Denicola wrote: I believe the cutover was decided in the September 25 meeting.
I must have missed it if so -- do the notes record it?
tc39/tc39-notes/blob/master/es6/2014-09/sept-25.md#conclusionresolution-1
bassed upon that I confirmed with Istvan that Ecma was ok with a document title change
However, I delayed actually change the cover page until the first draft release in 2015
That change was announced in the release notes: harmony:specification_drafts#january_15_2015_draft_rev_31
And highly visible to anybody who looks at the front cover: harmony:working_draft_ecma-262_edition_6_01-15-15.pdfharmony:working_draft_ecma-262_edition_6_01-15-15.pdf
Allen
[cid:imagefa2301.JPG at 9d06c775.4d92698a] Alexandre Morgaut Wakanda Community Manager Email : Alexandre.Morgaut at 4d.com<mailto:Alexandre.Morgaut at 4d.com>
Web : www.4D.comwww.4D.com
4D SAS 60, rue d'Alsace 92110 Clichy - France Standard : +33 1 40 87 92 00
[cid:image7b7bae.BMP at 0959e748.4aa394b0]www.4d.com/fr/company/events/summiteu2014.html
Aaron Frost wrote:
Trying to understand the cadenced release process. In the past a Final Draft would be cut and allowed to bake for 12 months before an Official Approval by the Ecma General Assembly. Is that 12-month bake still going to be in place?
More like six months, really -- Allen can give even more precise time tables.
Thanks Allen, same as Brendan, always on the HTML version. My bad.
However, it's not perfectly clear where the living standard name has been decided as such.
With all little things that could have made in ES6 but nobody wanted to rush in, realizing at 2 months from the final spec that the name everyone talked about changed was more than a surprise, hence my WTF reaction.
I still find weird the year-name label convention but I start understanding the why and its goal.
Please consider the switch for ES7 and maybe drop the 7th bit from the spec page.
Best
For what it matters, I've summarized my thoughts and described the problem here: webreflection.blogspot.de/2015/01/javascript-and-living-ecmascript.html
I know here it looks like I've been just a drama queen, but I think naming milestones are a better approach and brought better results to the JS community.
You all know what's best for the specs though, so I'll drop further comments here.
Best
On Jan 22, 2015, at 11:29 PM, Alexandre Louis Marc Morgaut wrote:
It may change, but based on the current cover, it looks like Booth ES6 and ECMAScript 2015 names could be right to use
The cover says:
- "Standard ECMA-262"
- "6th edition / Draft January 15, 2015"
- "ECMAScript 2015 Language Specification"
If an edition number is maintained, then anyone could either say ES6 or ES2015 and next anyone could say ES7 or ES2016
Now, I don't know if you intend to let "6th edition" in this form or switch it for "2015 edition" in some next publications
Just like on that page. The official Ecma document number will be "ECMA-262-6" read as ECMA-262, 6th Edition" The publication date will be "June, 2015"
All that has changed is that "2015" was added to the document title. It just means "this is the 2015 specification of ECMASript" whether the next edition after that is in in "2016" or "2040" hardly seem relevant.
How it is actually referred to by JS users will be something that is emergent. But, assuming that TC39 is successful at issuing yearly updates, it's going to be confusing around the time we get to 2025 (Edition 16??) and somebody needs to ask: why hasn't BMW implemented the geo location properties from ES13 yet? (or was it 14, no maybe ES12).
On Jan 23, 2015, at 12:08 AM, Aaron Frost wrote:
Trying to understand the cadenced release process. In the past a Final Draft would be cut and allowed to bake for 12 months before an Official Approval by the Ecma General Assembly. Is that 12-month bake still going to be in place?
I can only speak about ES5 (don't know about ES1,2,3 but a I'm pretty sure there wasn't a year long bake period before each of those).
The 12 month make was has been aspirational, but the reality is messier.
For ES5 we issued the first "Candidate Final Draft" in April 2009, a TC39 "Approval Draft" Sept 1, 2009 (it was approved by TC39 Sept 23, 2009) and we then released the final document (with minor editoral corrections) into the Ecma GA approval process. The Ecma GA accepted in as a standard at the Dec. 2009 meeting.
For ES6, we tried to say we were feature complete in Jan 2014 but the reality is that it wasn't until either the June or July meeting that we firmly closed the door on new features. Most of the changes that have occurred since then have been about cutting, completing or fixing the specification (and where necessary the design) of features that had already been accepted into the spec.
If this 12-month bake is still around, that would mean that the Final Draft for ES 2016 will need to be cut by June of this year, so that it can bake for 12 months and be ready by June 2016 for an Official Approval. This would mean that features not hardened enough by June 2015 will not make it into ES 2016.
If this is not how it will work, could you share the expected process of future releases? I am very interested to hear how it will work.
Working backwards, here is the end game for ES6 release:
Early June 2015: Ecma GA approval at their semi-annual meeting April 1-June (Ecma CC and GA review period, editorial preparation of publication document) March 26, Approval of Final Draft at March 24-26 TC39 meeting this is the last date that TC39 can approve and achieve June GA approval after this point, the only changes can be minor editorial or technical bug correction that don't require TC39 review Feb. 20, Final Approval Draft Release Member organization need at least 30 days before voting to approve Reported bugs will continue to be fixed Feb 2-19, Editor frantically incorporates Jan. meeting technical changes plus technical and editorial bug fixes to produce final draft. Jan 27-29, TC39 meeting Produce a small set of final technical changes for the editor to apply This must be a very small delta from current spec. as there is really no time for major spec. change or for another technical review cycle
(At various points in the above schedule, the editor may release intermediate draft updates)
Feb 2-19, Editor frantically incorporates Jan. meeting technical changes
No pressure! : )
(and thanks)
On Jan 23, 2015, at 2:15 AM, Andrea Giammarchi wrote:
Thanks Allen, same as Brendan, always on the HTML version. My bad.
However, it's not perfectly clear where the living standard name has been decided as such.
tc39/tc39-notes/blob/master/es6/2014-09/sept-25.md#conclusionresolution
On Jan 23, 2015, at 9:41 AM, Kevin Smith wrote:
Feb 2-19, Editor frantically incorporates Jan. meeting technical changes
No pressure! : )
I should have added: "and dozen of new typos"
Feb 2-19, Editor frantically incorporates Jan. meeting technical changes
No pressure! : )
I should have added: "and dozen of new typos"
Come on, where's your programmer's optimism?
On Jan 23, 2015, at 10:11 AM, Kevin Smith wrote:
Feb 2-19, Editor frantically incorporates Jan. meeting technical changes
No pressure! : )
I should have added: "and dozen of new typos"
Come on, where's your programmer's optimism?
I said "dozens" rather "hundreds"
Allen Wirfs-Brock wrote:
I can only speak about ES5 (don't know about ES1,2,3 but a I'm pretty sure there wasn't a year long bake period before each of those).
Nope.
@all
Should we rename this list to es-bikeshed? Seems to fit with the theme here. ;)
In all reality, I'm strongly considering asking Oracle about the specific enforcement status of the "JavaScript" trademark. If (and when) I do, I'll forward as much information as I can here.
[...] asking Oracle [...]
If they both read it and reply (you have a decent chance of getting one or the other, both is unlikely).
- Axel Rauschmayer wrote:
I’m in the process of coming up with a good title for a book on ECMAScript 6. That begs the question: What is the best way to refer to ECMAScript 6?
- The obvious choices: ECMAScript 6 or ES6.
- Suggested by Allen [1]: JavaScript 2015.
The advantage of #2 is that many people don’t know what ECMAScript 6 is. However, I’m worried that a book that has “2015” in its title will appear old in 2016.
Well, Microsoft Office 1997 came out in 1996, Office 2000 in 1999... So, "JavaScript 2016" would be a better title for marketing purposes. There is also the option leap ahead a bit further with "JavaScript 3000", but Python tried that already. Over in the lands of Perl 5 "Modern Perl" is the catchphrase booktitle, but that seems to be taken for JavaScript. It would also be possible to take a clue from the browser vendors and make it a BoD or e-book offering and increase the version number ever six weeks or so (clearly justified by folding in errata). Another option is to make reference to the past, like "Post-Snowden JavaScript" or better perhaps "JavaScript after Snowden". Might make for a good setup to talk about OO-design, classes, information hiding, and so on...
I’m in the process of coming up with a good title for a book on ECMAScript 6. That begs the question: What is the best way to refer to ECMAScript 6?
The advantage of #2 is that many people don’t know what ECMAScript 6 is. However, I’m worried that a book that has “2015” in its title will appear old in 2016. And the year scheme completely breaks with current tradition. I see two possibilities:
Axel
[1] twitter.com/awbjs/status/558316031039381504