Hi,
at the moment we are evaluating Corteza and we are very impressed by its broad feature set.
One (or the only?) issue seems to be that Corteza seems to use outdated versions of golang (1.19) and Vue (2.x). Are there concrete plans (maybe with a rough ETA) to update these to supported versions?
I am aware that Corteza is community driven and is only able to evolve with contributions. My team is interested in contributing to Corteza in the future (if we decided to use it) but updating the underlying core stacks might not be a good starting point…
Thanks!
I can speak for vue, it will stay 2.
Moving to 3 is not a trivial thing at all, requires a lot of hours to do so.
OK, sad to hear that. Many companies have SLAs prohibiting the use of unsupported versions.
Is Migration Build | Vue 3 Migration Guide an option that could work? Or are there serious obstacles (dependencies incompatible to Vue 3, …) that make migration in Corteza difficult?
You’re always free to clone the repository and try it yourself.
No vue migration is planned or will be done anytime soon.
OK, we’ll check if this is doable on our side, maybe using One-webapp as a poc.
If successful: Would you accept a PR with migration to Vue 3 (and support its stabilization) or is staying at Vue 2 a set/immutable project’s policy?
I would accept releasing a vue3 version, but we will not be actively supporting/maintaining it.
Plus we don’t have resources in the near future to do this.
A bad port to vue3 does nothing good except introducing vulnerabilities.
We have a bunch of libraries that don’t have vue3 support, so replacing that, reimplementing fixing bugs testing. Is similar to developing a new app.
Hi @johannes. I think it’s worth setting up a call to discuss in any case. Could you please send me an email to niall.mccarthy@crust.tech?
I agree that replacing libraries is a huge effort. I hoped that migration build (though not being an extremely “pretty” solution) could help to bypass the need of replacing libraries and at the same time solve the SLA problem of Vue 2.
I am not sure if I agree with this. What do you mean? I don’t claim that Vue 3 per se is more secure than Vue 2 but Vue 2 has the problem of being EOL. In case of vulnerabilities Vue 3 will get an update, Vue 2 will not.
yarn audit of the current Corteza webapps lists quite a few critical and high vulnerabilities. Many of these might be solved with updating (at least) to the latest Vue 2 libs/tooling. Are there any plans in this regard?
Yes, a migration build using the composition-api would be the way to go for now. Im speaking more of there could be potential bugs with some libraries and composition API/vue3, so that would be the bigger problem here if it happens.
By bad port, I meant a rushed one, where we don’t notice possible edge cases introduced by the update.
Regarding upgrading to the latest vue2 libs, yes that is planned but can only get us so far.
The same applies to all updates, possible conflicts with upgrade lib versions, etc.
OK, agreed.
I will do some rough experiments regarding migration build to get an idea if it could work. But further work on this path has only value for us if the project is willing to switch to and maintain the Vue 3 path. Maybe in the future…
In the meanwhile looking forward to the updated Vue 2 implementation.