Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: remove semver from dependencies #160

Merged
merged 1 commit into from Apr 8, 2020
Merged

refactor: remove semver from dependencies #160

merged 1 commit into from Apr 8, 2020

Conversation

arturovt
Copy link
Collaborator

@arturovt arturovt commented Apr 7, 2020

Joel, this check for Angular has to be removed in the future IMO, because Angular 7 LTS ends on 18 April 2020. We'd want to maintain only stable versions.

Copy link
Member

@joeldenning joeldenning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I didn't know angular core exported its version like this, that is nice.

Joel, this check for Angular has to be removed in the future IMO, because Angular 7 LTS ends on 18 April 2020. We'd want to maintain only stable versions.

I disagree, actually. One of the main pitches of single-spa is to convert an old legacy system into a single-spa application so that you can use newer frameworks for new code. We have to support older versions of Angular (at least a little bit) to help people in that situation.

@joeldenning joeldenning merged commit 7a17013 into single-spa:master Apr 8, 2020
@arturovt arturovt deleted the remove-semver branch April 8, 2020 17:56
@arturovt
Copy link
Collaborator Author

arturovt commented Apr 8, 2020

Ah I didn't know angular core exported its version like this, that is nice.

Joel, this check for Angular has to be removed in the future IMO, because Angular 7 LTS ends on 18 April 2020. We'd want to maintain only stable versions.

I disagree, actually. One of the main pitches of single-spa is to convert an old legacy system into a single-spa application so that you can use newer frameworks for new code. We have to support older versions of Angular (at least a little bit) to help people in that situation.

That might be complicated to accomplish, I'm not saying we should drop support for older or something similar, but we have to consider that idea.

If someone wants to start a new application and as you said can use newer frameworks for new code then he will start that application with the latest stable version. E.g. if we would have had some old legacy then we would start with the latest React (not with 15 I'm sure :D) and not with Angular 6 or 7, that sounds pragmatic and reasonable. Fix me if I'm wrong at some moments.

People will still be able to use single-spa-angular@some-version-that-still-supports-5-or-7 with Angular 5-7.

@joeldenning
Copy link
Member

Yeah so I'm thinking single-spa-angular@3 will continue to exist as a way to support Angular 2-7. And single-spa-angular@4 can support Angular 8-9. As new Angular versions come out, we choose whether to release a new major version of single-spa-angular or not for them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants