Discourse에서 사용되는 Ember 버전을 업데이트하고자 합니다.
현재 3.15 버전을 사용 중이며, 4.1 버전으로 업그레이드하는 것이 목표입니다.
이번 작업을 올해 말까지 완료하는 것을 목표로 하고 있습니다. 이 토픽은 로드맵이며, 모든 계획과 추정치는 잠정적인 것입니다. 이 토픽은 특정 업그레이드나 변경 사항에 대한 중요한 논의를 위한 공간이 아닙니다. 따라서 여기에서의 대화를 다소 집중적으로 유지합시다. 이러한 업데이트가 여러분의 사이트/플러그인/테마에 어떤 영향을 미칠지에 대한 질문은 오프토픽입니다. 계획된 변경 사항은 100% 프론트엔드(Ember 앱)에 국한됩니다.
우리는 도입할 변경 사항에 대해 매우 신중할 것입니다. 모든 공식 플러그인/테마가 업데이트될 것입니다 (CDCK가 고객들을 위해 수행한 모든 커스텀 작업 포함). 또한 인기 있는 비공식 플러그인/테마를 업데이트하기 위해 PR을 보내겠습니다.
여러분이 자신의 사이트를 위해 직접 만든 커스텀 플러그인/테마가 있다면 걱정하지 마세요. 필요한 변경 사항을 수행할 수 있도록 충분한 시간을 드리기 위해 적시에 비추천(deprecation) 경고와 필요한 공지사항을 게시하겠습니다. 필요시 이러한 변경 사항에 대해 안내도 드릴 것입니다.
목표부터 시작해 보겠습니다. 당연히 가능한 가장 높은 버전으로 이동하는 것이 목표이지만, 현재부터 최종 목적지까지 중간 목표를 설정해야 합니다.
우리는 점진적인 업데이트를 수행할 계획입니다. 4.1로 한 번에 대규모 업데이트하는 대신, 이 작업을 여섯 단계로 나누어 진행하겠습니다. 각 단계는 하나의 Ember 업데이트에 초점을 맞춥니다.
| 단계 | 규모 | 업데이트 내용 |
|---|---|---|
| 1 | size-l | Ember 3.15 → Ember 3.16 |
| 2 | size-m | Ember 3.16 → Ember 3.25 |
| 3 | size-xl | Ember 3.25 → Ember 3.26 (Part 1 - 일반) Ember 3.25 → Ember 3.26 (Part 2 - 템플릿) Ember 3.25 → Ember 3.26 (Part 3 - jQuery) Ember 3.25 → Ember 3.26 (Part 4 - Octane 준비 작업) Ember 3.25 → Ember 3.26 (Part 5 - Octane) |
| 4 | size-l | Ember 3.26 → Ember 3.27 (Part 1 - 일반) Ember 3.26 → Ember 3.27 (Part 2 - RenderTemplate) Ember 3.26 → Ember 3.27 (Part 3 - 레거시 내장 컴포넌트) |
| 5 | size-s | Ember 3.27 → Ember 3.28 |
| 6 | size-s | Ember 3.28 → Ember 4.1 |
이러한 특정 버전을 선택한 것은 전적으로 해당 버전이 도입하는 비추천 항목과 작업량, 그리고 암시되는 위험도에 기반하고 있습니다.
자, 더 명확하도록 이를 자세히 나눠 보겠습니다.
업데이트별 비추천 항목
Stage 1 (size-l)
Ember 3.15 → Ember 3.16
이 업데이트는 하나의 비추천 항목만 도입합니다.
-
레거시 글로벌 리졸버 대신 ember-CLI 리졸버 사용
- 종료: 4.0.0 - size-lDiscourse는 현재
Ember.DefaultResolver를 확장하는 자체 커스텀 리졸버를 가지고 있습니다.권장되는 수정 방법은 커스텀 리졸버를 모두 제거하고 Ember-CLI 리졸버를 사용하는 것입니다. 플러그인과 테마를 처리하기 위한 상당한 양의 커스텀 로직이 있기 때문에 말하기는 쉽지만 실행하기는 어렵습니다.
작동하는 절충안은
Ember.DefaultResolver를 확장하는 대신 Ember-CLI 리졸버를 확장하는 것입니다.
Stage 2 (size-m)
Ember 3.16 → Ember 3.25
이 업데이트는 여덟 개의 비추천 항목을 도입합니다.
-
@ember/string#loc및{{loc}} 종료: 4.0.0 - 
-
Without for - Ember의 내장 비추천
종료: 4.0.0 - -
Without since - Ember의 내장 비추천
종료: 4.0.0 - -
@ember/utils의 tryInvoke
종료: 4.0.0 - -
Meta Destruction API
- 종료: 3.25.0 - 우리는 이것들을 사용하지 않으므로 여기서는 할 일이 없습니다.
-
Ember getter 사용 및 undefined 명시적 확인 - 종료: 4.0.0 - size-s이것은 단순한 비추천 항목입니다. 코드베이스에서getWithDefault를 제거할 필요가 있으며, 이를 사용하는 곳은 몇 군데뿐입니다. -
String 프로토타입 확장 - 종료: 4.0.0 - size-m이것도 단순하고 리스크가 낮은 교체 작업이지만, 우리는 Ember의 확장된 String 프로토타입을 꽤 많은 곳에서 사용합니다. 빠른 확인 결과, 코어와 플러그인/테마를 합쳐서 약 100곳 미만에서 그렇게 하고 있는 것으로 보입니다.해당 부분을 업데이트한 후에는, 다음과 같은 것으로 Ember가 해당 프로토타입을 확장하는 것을 방지해야 합니다.EXTEND_PROTOTYPES: { String: false }이를 우리의 environment 파일에 추가해야 합니다.
-
@ember/string에서htmlSafe및isHTMLSafe가져오기 - 종료: 4.0.0 - size-m이 업데이트에서 이 항목과 #7 사이에 상당한 중복이 있으며, 직관적이고 리스크가 낮아야 합니다.
Stage 3 (size-xl)
3.25에서 3.26으로의 업그레이드는 상당히 복잡한 과정입니다. 여기서 대부분의 “추격” 작업이 이루어집니다. 총 열여섯 개의 비추천 항목이 있습니다. 이 업데이트를 다섯 부분으로 나누어 진행할 계획이며, 모든 비추천 항목이 처리된 후에만 버전 업을 수행합니다.
Ember 3.25 → Ember 3.26 (Part 1 - 일반)
이 부분은 상대적으로 처리하기 쉬운 아홉 개의 비추천 항목을 다룹니다.
-
Array Observers
- 종료: 4.0.0 - -
Component Manager Capabilities
- 종료: 4.0.0 - -
Modifier Manager Capabilities
- 종료: 4.0.0 - -
Optional Feature: application-template-wrapper
- 종료: 4.0.0 - -
템플릿 내 인수로 사용된 classBinding 및 classNameBindings
- 종료: 4.0.0 - 여기서는 할 일이 없습니다. 우리는 이것들을 사용하지 않습니다.
-
루트 및 컨트롤러의 Transition 메서드
- 종료: 5.0.0 - size-m이 비추천 항목은
routes와controllers에서 몇 가지 메서드를 제거합니다. 복잡한 변경 사항처럼 보일 수 있지만, 직관적이어야 합니다. 필요한 경우에만Router를 서비스로 주입하고 거기서 호출하도록 하면 됩니다. 어려운 점은 우리가 많은 곳에서 이것들을 사용하며, 모두 업데이트해야 한다는 것입니다. -
브라우저 지원 정책 - 종료: 4.0.0 - size-s~~이것은 상대적으로 단순한 변경 사항이어야 합니다. Ember는 4.0부터 IE11을 지원하지 않습니다. 좋은 점은 우리가 이미 오랫동안 IE11을 지원하지 않았다는 것입니다. 우리가 변경해야 할 유일한 것은 프로덕션 환경에서 IE11을 위한 트랜스파일링을 중단하는 것입니다.
discourse/app/assets/javascripts/discourse/config/targets.js at 1472e47aae5bfdfb6fd9abfe89beb186c751f514 · discourse/discourse · GitHub저는 몇 가지 기본적인 테스트를 해보았는데, 이 변경 사항은 프로덕션 Ember-CLI 설치에서 메인 및 벤더 번들의 약 60kb(gzip) 또는 약 6%를 절약해 줄 것입니다. -
{{hasBlock}} 및 {{hasBlockParams}} - 종료: 4.0.0 - size-s우리는 몇 군데에서 이것들을 사용합니다. 이것은 단순하고 리스크가 낮은 이름 변경입니다. -
{{with}}헬퍼 - 종료: 4.0.0 - size-s우리는 이걸 거의 사용하지 않지만, 여전히 수정이 필요합니다. 단순히 그것들을 교체하고{{let}}또는{{if}}/{{else}}의 조합을 사용하면 됩니다.
Ember 3.25 → Ember 3.26 (Part 2 - 템플릿)
이 부분은 주로 .hbs 템플릿과 관련된 비추천 항목에 초점을 맞출 것입니다. 여기서 집중해야 할 세 개의 비추천 항목이 있습니다.
-
Property Fallback Lookup
- 종료: 4.0.0 - size-lEmber 4.0부터는 이것이 더 이상 작동하지 않습니다.
Hello, {{name}}!템플릿에 프로퍼티가 있는 경우, 다음과 같이 앞에
this를 붙여 조회해야 합니다.Hello, {{this.name}}!우리의 모든 템플릿에서 그렇게 해야 합니다. 여기에서 고통을 줄이는 방법이 있습니다. ember-no-implicit-this-codemod을 시도해 보고 얼마나 멀리 갈 수 있는지 확인해 볼 수 있습니다.
저는 변경 사항을 PR당 1개 파일로 제한하는 것을 지지합니다. 이렇게 하면 리뷰가 쉬워지고, 문제가 발생하면 되돌리기也容易합니다.
-
{{attrs}}를 통한 이름 지정 인수 접근
- 종료: 4.0.0 size-xl{{attrs}}객체는 Ember 4.0에서 제거될 예정입니다. 변경 자체는 매우 직관적이고, Ember의 예시도 꽤 좋습니다.변경 전:
{{attrs.foo}} {{this.attrs.foo.bar}} {{deeply (nested attrs.foobar.baz)}}변경 후:
{{@foo}} {{@foo.bar}} {{deeply (nested @foobar.baz)}}우리는 모든 템플릿에서 이렇게 해야 합니다. 이 변경 사항을 템플릿을 앵글 브래킷 구문으로 변환하는 작업과 결합할 수 있습니다. 저는 앵글 브래킷을 강력히 지지하는데, 표준 커스텀 웹 컴포넌트 구문에 훨씬 더 가깝기 때문입니다.
여기에서 우리의 진전을 가속화할 수 있는 것 중 하나는 ember-angle-brackets-codemod입니다. 우리는 이것을 실험해 보고 얼마나 멀리 갈 수 있는지 확인해야 합니다. 이것은 비추천 항목을 처리하고 우리에게 빛나는 앵글 브래킷 구문을 제공합니다.
이 부분의 #1과 마찬가지로, 저도 PR당 템플릿 하나를 수정하고 테스트하는 것을 지지합니다.
-
<LinkTo>위치 인수 - 종료: 4.0.0 - size-m이것도 혼란을 줄이려는 비추천 항목입니다. link-to에 위치 인수를 사용하는 곳이 몇 군데 있습니다. 다음과 같이 수정할 수 있습니다.
변경 전:
{{link-to "About Us" "about"}} {{#link-to "about"}}About Us{{/link-to}} {{#link-to "post" @post}}Read {{@post.title}}...{{/link-to}}변경 후 (앵글 브래킷 사용):
<LinkTo @route="about">About Us</LinkTo> <LinkTo @route="about">About Us</LinkTo> <LinkTo @route="post" @model={{@post}}>Read {{@post.title}}...</LinkTo>
Ember 3.25 → Ember 3.26 (Part 3 - jQuery)
이 부분에 대해 여러분이 이미 알고 있는 것 외에 제가 더 말할 것은 많지 않습니다. 새로운 Ember 앱은 jQuery를 사용하지 않으며, Ember 4.0에서 제거될 예정입니다.
이 부분에서는 하나의 비추천 항목에 초점을 맞출 것입니다.
-
Optional Feature: jquery-integration
- 종료: 4.0.0 - size-xl지난 몇 년간 우리는 jQuery 사용량을 줄이는 데 상당한 진전을 이루었습니다. 여전히 필요한 곳이 있으며, 특히 컴포저(composer)와 우리가 사용하는 일부 벤더 라이브러리의 종속성에서 그렇습니다. 여기서는 이 변경 사항의 세부 사항에 깊이 들어가지 않겠습니다. 결론적으로, 우리는 jQuery 사용을 중단해야 합니다.
그러나, 만약 우리가 EVERYWHERE에서 jQuery를 제거하더라도, Ember 4.0에 대비할 준비가 될 때까지 이 옵션을 true로 유지해야 한다고 강조하고 싶습니다. 우리가 통제하지 않는 커스텀 테마/플러그인이 있는 사이트의 전환을 부드럽게 만들기 위한 계획이 필요합니다.换句话说, 작업을 수행하되 옵션을 끄는 것에 대한 비추천 경고는 감수합시다.
Ember 3.25 → Ember 3.26 (Part 4 - Octane 준비 작업)
이 부분에서는 우리의 파일들이 Octane에 대비할 수 있도록 준비하는 데 초점을 맞춰야 합니다. 우리는 두 개의 비추천 항목을 처리할 것입니다.
-
Optional Feature: template-only-glimmer-components
- 종료: 4.0.0 - size-m이론적으로는 단순한 변경이지만, 그 옵션을 토글하기 전에 수행해야 하는 암시적인 작업이 있습니다.
우리의 현재 템플릿 전용 컴포넌트가 glimmer 시맨틱과 함께 작동하는지 확인해야 합니다. 저는 몇 가지 테스트를 해보았는데, 그 옵션을 켜자 테스트가 실패했습니다. 코어에 있는 템플릿 전용 컴포넌트의 예시 목록은 다음과 같습니다.
- app/templates/components/activation-email-form.hbs - app/templates/components/cancel-link.hbs - app/templates/components/categories-with-featured-topics.hbs - app/templates/components/category-name-fields.hbs - app/templates/components/color-input.hbs - app/templates/components/custom-html-container.hbs - app/templates/components/emoji-group-buttons.hbs - app/templates/components/emoji-group-sections.hbs - app/templates/components/empty-state.hbs - app/templates/components/ip-lookup.hbs - app/templates/components/modal-footer-close.hbs - app/templates/components/popup-menu.hbs - app/templates/components/reviewable-created-by-name.hbs - app/templates/components/reviewable-created-by.hbs - app/templates/components/reviewable-field-editor.hbs - app/templates/components/reviewable-field-text.hbs - app/templates/components/reviewable-field-textarea.hbs - app/templates/components/reviewable-field.hbs - app/templates/components/reviewable-flagged-post.hbs - app/templates/components/reviewable-post-header.hbs - app/templates/components/reviewable-post.hbs - app/templates/components/reviewable-scores.hbs - app/templates/components/reviewable-tags.hbs - app/templates/components/reviewable-topic-link.hbs - app/templates/components/score-value.hbs - app/templates/components/selected-posts.hbs - app/templates/components/subcategories-with-featured-topics.hbs - app/templates/components/text-overflow.hbs - app/templates/components/user-fields/confirm.hbs - app/templates/components/user-fields/dropdown.hbs - app/templates/components/user-fields/multiselect.hbs - app/templates/components/user-fields/text.hbs - app/templates/components/user-profile-avatar.hbs - app/templates/components/user-summary-users-list.hbs또한 Admin/테마/플러그인 템플릿을 확인하고, 그 옵션을 배포하기 전에 모든 것이 정상 작동하는지 확인해야 합니다.
바로 떠오르는 바로는, 우리의 raw
.hbr템플릿이 이 안에 어떻게 들어맞는지 정확히 확신이 서지 않습니다. 그러나 @david는 glimmer 기반의 토픽 목록을 작업하고 있습니다. 따라서, raw 템플릿을 완전히 폐기할 수도 있습니다. -
Implicit Injections
- 종료: 4.0.0 size-xl우리는 모든 곳에서 implicit injections를 사용합니다. 우리는 다음과 같은 이니셜라이저(initializer)에서 이렇게 합니다.
discourse/app/assets/javascripts/discourse/app/pre-initializers/inject-discourse-objects.js at ac79c5efc61d259705eeb487ca21d0ec3c535807 · discourse/discourse · GitHubEmber는 implicit injections에서 멀어지고 있습니다. 권장되는 방향은 가능한 한 많은 객체를 서비스로 변환하고, 필요한 곳에서 명시적으로 주입하는 것입니다. 물론, 서비스가 이상적이지 않을 수 있는 몇 가지 경우가 있을 것입니다. 그런 경우, 다음과 같이 필요한 시점에 해당 객체를 직접 조회할 수 있습니다.
getOwner(this).lookup('thing:main')우리가 가진 또 다른 옵션(성능 영향에 따라)은 Ember Classes를 우리의 자체 Discourse Class로 래핑하는 것입니다. 그러면 우리는 앱 전체에서 우리의 Class를 사용하게 됩니다.
GlimmerComponent Class를 사용하는 방식과 비슷합니다.
discourse/app/assets/javascripts/discourse/app/components/glimmer.js at fa0c796baf9a7f64a3b27823b1aa4b370a74c3eb · discourse/discourse · GitHub. 이렇게 하면 이 작업을 size-l 또는 심지어 #size-m으로 만들 수 있습니다.어쨌든, 이 변경 사항에는 일부 사고가 필요합니다.
Ember 3.25 → Ember 3.26 (Part 5 - Octane)
이것은 3.25 → Ember 3.26 업그레이드의 마지막 구간입니다. 이 시점에서 우리는 하나의 비추천 항목만 남게 되지만, 그것은 큰 것입니다.
-
Edition: Classic
- 종료: 4.0.0 - size-xl버전을 Octane으로 전환하기 전에, 우리의 Classes를 네이티브 Classes로, 그리고 컴포넌트를 Glimmer 컴포넌트로 변환하는 데 시간을 보내고 싶습니다. 약간의 고통이 따를 것이지만, 그만한 가치가 있습니다. ember-native-class-codemod은 그 고통을 덜어줄 것입니다. 우리는 그것이 우리를 얼마나 멀리 데려다 줄지 확인해 봐야 합니다.
고려해야 할 사항과 워크플로우 문제가 많습니다. 제가 강조하고 싶은 유일한 것은, 이것이 제가 템플릿에 대해 언급했던 것과 동일한 흐름을 따를 것이라는 점입니다 - PR당 컴포넌트 하나를 수정하고 테스트합니다.
Stage 4
Ember 3.26 → Ember 3.27 업데이트는 열두 개의 비추천 항목을 도입합니다. 저는 그것들을 세 부분으로 나누자고 제안합니다. 모든 비추천 항목이 처리된 후에 버전 업을 수행할 것입니다.
Ember 3.26 → Ember 3.27 (part 1 - 일반)
-
Reopening Classic Component Super Class
- 종료: 4.0.0 - -
Class-based template compilation plugins
- 종료: 4.0.0 - -
LinkTo @disabled-when argument
- 종료: 4.0.0 - 우리는 이것들을 사용하지 않는다고 생각하므로, 여기서는 할 일이 없습니다.
-
Route#disconnectOutlet비추천 - 종료: 4.0.0 - size-s우리는 단 한 곳에서만 이것을 수행합니다.
build-category-route이며, 수정하기가 직관적이어야 합니다. -
인수와 괄호 없이 이름 지정 인수 위치에서 헬퍼 호출
- 종료: 4.0.0 - size-s우리는 아무 데도 이렇게 하지 않는다고 생각하지만, 때가 되면 확인하겠습니다. 기본적으로, 인수를 전달하지 않고 헬퍼를 호출하는 것입니다.
우리가 그런 것을 사용한다고 해도, 우리는 단순히 괄호를 추가하면 됩니다. 즉, 이것
<SomeComponent @arg={{someHelper}} />은 다음과 같이 됩니다.
<SomeComponent @arg={{(someHelper)}} />someHelper주위의 괄호에 주목하세요. -
Run loop and computed dot access
- 종료: 4.0.0 - size-m우리는
decorators애드온에서.를 사용하여computed함수에 접근합니다. 예를 들어, 그들은 이렇게 보입니다.
discourse/app/assets/javascripts/discourse-common/addon/utils/decorators.js at b05fddaa7ce3968ffc70cd8d4bf290e15d06eb11 · discourse/discourse · GitHub또한 여기저기 단발성으로 하나씩 있는 경우도 있습니다. 제가 볼 수 있는 한, 그것들을 수정하는 것은 주로 우리가 어떻게 가져오는지를 수정하는 것에 관한 것입니다.
즉,
computed.filter는 이제 다음과 같이 가져와야 합니다.import { filter } from '@ember/object/computed';외부 벤더
buffered-proxy애드온의 우리의 버전은computed함수에 접근하기 위해.를 사용합니다. 우리는 그것을 업데이트해야 합니다.또한 우리는 몇몇 곳에서
run함수에 접근하기 위해.를 사용합니다. 그렇지만, 동일한 수정이 적용됩니다. 우리가 어떻게 가져오는지를 업데이트해야 합니다. 특히 테마와 플러그인에서는run에 대해 그렇게 하는 곳이 꽤 많을 것이라고 생각합니다. -
Ember Global 비추천
- 종료: 4.0.0 - (#size ?)4.0 이후로
Ember는 글로벌 컨텍스트에서 사용할 수 없게 됩니다. 더 깊은 조사가 없다면 여기의 작업량/영향을 추정하기는 어렵습니다. 그렇지만, @cvx가 이 패턴을 제거하기 위해 많은 작업을 해왔다는 것을 알고 있습니다.
Ember 3.26 → Ember 3.27 (part 2 - renderTemplate)
이 부분은 하나의 비추천 항목에만 초점을 맞출 것입니다.
-
Route#renderTemplate비추천 - 종료: 4.0.0 - size-l요컨대, 우리는 Ember 4.0에서 이름 지정 아웃렛(named outlets)을 사용할 수 없습니다. 따라서, 이것은 작동하지 않을 것입니다.
{{outlet "thing"}}우리는 코어에서만 거의 30곳에서
renderTemplate을 사용합니다. 업그레이드 자체는 꽤 직관적으로 보입니다. 우리는{{#in-element}}와 이름 지정 아웃렛에서 렌더링하던 것을 위한 플레이스홀더로 단순한 빈 HTML 요소를 사용할 수 있습니다.
Ember 3.26 → Ember 3.27 (part 3 - 레거시 내장 컴포넌트)
이 부분은 내장 레거시 컴포넌트에 초점을 맞출 것이며, 네 개의 비추천 항목을 처리할 것입니다.
- 레거시 내장 컴포넌트 가져오기 - 종료: 4.0.0
- 내장 컴포넌트 레거시 인수 - 종료: 4.0.0
- 내장 컴포넌트 레거시 HTML 속성 인수 - 종료: 4.0.0
- 레거시 내장 컴포넌트 Reopening - 종료: 4.0.0
저는 이것들에 크기를 추가하지 않았습니다. 왜냐하면… 정말로 상황에 따라 다르기 때문입니다. 설명해 드리겠습니다.
Checkbox, TextField, TextArea, LinkComponent와 같은 레거시 내장 컴포넌트는 Ember 4.0에서 제거될 것입니다. 우리는 그것들을 꽤 많은 곳에서 사용하며, 또한 그것들에서 일부 비추천 패턴도 사용합니다.
Ember는 우리가 그것들을 계속 사용할 수 있도록 업그레이드 경로를 제공하지만, 우리는 그것들을 다르게 가져와야 합니다. 그러나, 그것들은 Ember로부터 더 이상 업데이트를 받지 않고 동결된 상태로 남을 것입니다. 저는 그것들을 모두 폐기할 수 있기를 희망하지만, 그것은 다소 복잡할 수 있습니다. 이 변경 사항은 때가 되면 더 많은 논의가 필요합니다.
Stage 5
Ember 3.27 → Ember 3.28
이것은 버전 업만 있기 때문에 #size-s입니다. 3.28은 3.x 개발 주기에서 마지막 LTS 릴리스입니다. 3.27 이후 새로운 비추천 항목을 도입하지 않으며, 상황이 안정될 때까지 몇 주 동안 머물러 있기 좋은 버전입니다.
3.28 LTS는 2022년 8월까지 지원됩니다 (버그 수정 및 보안 패치 모두 포함).
이 "휴식"에는 몇 가지 이점이 있습니다.
- 문제가 발생하는지 확인하는 데 더 많은 시간을 줍니다.
- 안정적인 버전을 배포할 때, 그것은 3.28 위에 있어야 합니다.
- 자체 유지보수 테마 및 플러그인에 대해 필요한 공지를 할 시간을 줍니다.
- jQuery → no jQuery 전환이 최대한 매끄럽도록 보장하는 시간을 줍니다.
Stage 6
몇 주가 지나면, 마침내 우리의 버전을 Ember 4로 올릴 수 있습니다.
Ember 3.28 → Ember 4.1
이제 우리는 3.x 주기의 마지막 비추천 항목인 선택적 jQuery 통합을 꺼낼 수 있습니다.
이 업데이트는 두 개의 경미한 비추천 항목을 도입합니다.
-
Ember.assign 비추천 - 종료: 5.0.0 - size-s우리는 코어에서 그것을 사용하지 않지만, 테마/플러그인을 확인해야 합니다. 어쨌든, 그것은 단순한 이름 변경입니다. -
AutoLocation Class
- 종료: 5.0.0 - size-s이론적으로, 우리는 우리의 Ember environment 파일에서
locationType: 'auto'를locationType: 'history'로만 변경하면 되고, 그것으로 작동해야 합니다.
워크플로우
시작에서 언급했듯이, 우리는 이 업데이트들에 대해 매우 신중할 것입니다. 우리는 모든 업데이트마다 모든 공식 플러그인/테마를 테스트/수정/고정(pinned)할 것이며, 인기 있는 비공식 플러그인/테마에도 PR을 보내겠습니다.
여기서의 목표는 개발을 늦추거나 두통을 유발하는 것이 아닙니다. 따라서, PR은 엄격하게 범위가 제한되어야 하며, PR당 하나의 변경 사항만 포함하고 너무 크지 않아야 합니다.
이상적인 세계에서는, 모든 변경 사항이 다른 사람들의 작업을 방해하지 않고 백그라운드에서 일어나야 합니다. 이것이 우리가 PR을 짧고 간결하게 유지하려는 이유입니다. 또한, 우리는 혼합된 패턴을 좋아하지 않습니다. 따라서, 파일 단위로 중간 상태에 갇히기를 원하지 않습니다. 컴포넌트는 classic이거나 Glimmer이고, 템플릿은 중괄호를 사용하거나 앵글 브래킷을 사용하며, 그 사이에는 아무것도 없습니다.
이 로드맵이 명확했기를 바랍니다. 처음에 언급했듯이, 이것은 단지 일반적인 최상위 개요입니다. 만약 불분명하거나, 잘못되었거나, 마음에 들지 않는 부분이 있다면, 우리에게 알려 주십시오.
)
