Aurelia V1 Lifespan

vNext
1

With Aurelia v2 now around the corner, I’m eager to hear from the core team in regards to the future of the v1 codebase:

  1. Responding to identified vulnerabilities
  2. Responding to v1 GitHub Issues
  3. Committed v2 back-ports and triaging community requests

For enterprise, where might we inquire for consultation on roadmapping a large upgrade?

2 Likes
2

For the vulnerabilities that are related to application, they will be fixed, with high priority. For development purpose, we’ve been slacking here a bit, as it’s not as critical. Which one are you referring to?

For v1: beside the router: has a lot of issues because of its big surface, there hasn’t been any critical issue that went unaddressed (at least as far as I’m aware).
For v1 tooling, Webpack v5 is a quite an issue, and it seems like a big one to fix, this will probably take some more time until we can find our way through Webpack APIs & internal again.

For backporting, I’m not sure that we want to commit to this, maybe it will depend on the features. Do you have a particular one in mind? If it’s a general question, then maybe we can do it based on the popular community requests.

After Alpha gets more stable and ready, maybe we can afford to fix/refactor the v1 router more, but at the moment, it’s stable enough that it’s hard to justify the risk of creating more bugs via quick fixes.

If the answers above aren’t satisfying/on point, can you be more specific with the questions?

2 Likes
3

Thanks @bigopon as always for a prompt reply.

This was a pretty open-ended query which you satisfied for the most part. The only point you didn’t speak to was: where can we reach out to for enterprise support should we need guidance and/or assistance with planning and execution of upgrading v1 code to v2? Is BlueSpire still the go-to contact point?

To your questions:

  • For github issues, the only one on my radar I’m eager for traction on is aurelia-router #648 as it’s forced us to unsavory things (such as casting the router to any).
  • I don’t have any specific potential backports in mind. Only raised this as @fkleuver has mentioned a time or two that some V2 goodies might be candidates.
1 Like
4

For the router issue, it’s probably in the same timing with the general router refactoring. There’s a lot to be done, and can be done if time allows (I still have in my mind what I want to do/can do to fix/refactor). For casting the router to any, maybe you can declare a sub type of router and override the method so that it can returns a broader type, and cast to that type instead?

For backporting the goodies, I’m not 100% sure what we should do better. Any features that are in v2 but not in v1, they are probably in the form of plugins I’d guess (portal/@watch for examples…). If there’ some features that are good/desirable to port, I’d definitely not be hesitant/discouraging it. As far as I’m aware, we haven’t (and maybe won’t?) set a sunset date for v1. So beside the router issues & webpack upgrade that are giving the impression that v1 isn’t maintained, we are still committing to have v1 issues properly resolved. (I’ve fixed /refactored a few things recently).

3 Likes