RFC 0002: Project UniCore Intro 🦄

[Shazwazza]

A final comment period has been applied to this RFC and it will be accepted on 13/08/2019

---

See RFC document (in this PR): 0001-project-unicore-intro.md

Summary

Title: Project UniCore

We would like to proceed with moving the current Umbraco codebase from .Net Framework to be based on .Net Core.
We would like to make the porting of this code as simple as possible, both from the point of view of the engineers but more importantly the point of view of Umbraco end-users/developers.
Where possible, we hope to create a .Net Core build of Umbraco while keeping as many of the same existing APIs and paradigms that developers are currently used to.
We are calling this the “Minimal disruption” approach.

[JoseMarcenaro]

Great initiative! My five cents:

"Is this approach understandable?"

• Totally understandable

"Are there aspects of this approach missing?"

• My knowledge is not deep enough to answer that.

"Do you agree with the “Minimal disruption” approach? If not, why?"

• I totally agree, if it is possible. Although knowing how different the ASP.Net Core pipeline is - compared to the way ASP.Net 4.x works - I'm not sure how minimal that can be.

[Shazwazza]

A final comment period has been applied to this RFC and it will be accepted on 13/08/2019

This RFC is a parent RFC to what will be a number of child RFCs on the road to .Net Core. Based on a lot of feedback in meetups, user groups, etc... it seems like the approach being taken is on the correct path.

[JimBobSquarePants]

How can MSDI be out of scope? It’s critical that you build the application using the bare minimum of APIs provided by the MSDI abstractions otherwise you are subject to vendor lock-in.

[Shazwazza]

It will be considered, and probably worked, and probably implemented, but it is not in the 'critical path' to just get Umbraco working with the "Minimal disruption” on aspnetcore

[Shazwazza]

MSDI is also marked that it will be a separate RFC

[gfchaves]

Hi Shazwazza,

Great initiative indeed! Congrats. And for some of the questions I do believe that we had the opportunity to talk about them last year at Codegarden. But i'll try to leave here some suggestions and thoughts.

Is this approach understandable?

Yes, I agree.

Are there aspects of this approach missing?

Technical aspects? or Process ones?

Do you agree with the “Minimal disruption” approach? If not, why?

Well, i have mix feelings. Why? It's total understandable that a minimal disruption is required, not only buy the time to market, but also regarding the projects migrations that would be required. On another hand, and if HQ is taking this as a new "project" maybe it's time to approach with a more "clean" way and have a new solid struct for the upcoming years of the CMS. I think that in some areas .net core stills needs work and more endurance before be applied with enterprise grade solutions.

With a new solid base with a different approach, well prepared for top layers, the migration process could benefit of a new tool that could create and transform the data as needed. Also the community and the developers can have a new and more clear path to implement with best practices in mind.

I can't remember a product that has many years, and at some point has that special "breaking change" paradigm that force in some way to re-write, re-integrate the old solutions into the new clean and secure approach.

Although I agree that this could be a more painful method, but also a much more reliable for the future of the product. And of course many code and knowledge would have a direct mapping into the new solution., but other parts needs a much more deep change.

[Shazwazza]

@gfchaves Thanks for the comments :) I agree that at some stage it will be nice to revamp a few underlying things within Umbraco but I think there's always a first step to such things. I also don't think there's ever a need to 'rewrite' the whole thing or start from scratch. I think we can easily iterate on improvements over time and for the forseable future. Moving to .NET core is one of those improvements and i think should be treated as a standalone improvement. Purely based on the critical path in getting to .NET core will see some vast improvements to the underlying codebase naturally anyways. Even at the halfway point when the project split is complete and we're still using the .NET framework runtime, this will yield a much cleaner codebase by then too and the plan is that we don't really have to change a ton of code to make that happen because v8 has cleaned up a lot of this code already. We aren't taking this as a 'rebuild' or a new project, it will in fact be quite a transition of existing code.

[JoseMarcenaro]

@gfchaves - I understand some degree of "cleanup", but the "new project" concept scares me a little bit.
I keep thinking of some projects rebuilt from scratch that went too far and ended up splitting their community in halves (i.e. Angular 2) and I don't like that path for Umbraco...
Of course, this is an open discussion and every point of view is valuable - thanks for the opposing argument.

[gfchaves]

@Shazwazza - yes I mean, the code migration process and the fact of the v8 has already a much more clean code, I agree on. I was aiming more in implementation concepts and data structures, that could be more prepared for next challenges, and the new "fancy" stuff that is coming around every product or cloud. :)

If you're taking as a transition of existing code to be built on .net core, and tacking some minor stuff around, it's more likely to be a smooth transition - it's ok. Maybe some of the core stuff that we've always dream about it should go on another future version. Also I need to re-check with the V8 core changes to have a much precise suggestions. - but i'll talk ;-)

@JoseMarcenaro - I never saw this has a new "project" that could in anyway split the community, you gave the angular case, but I can talk for instance the ubuntu community. You have those who their focus is the vnext that in a fixed time will converge for the LTS version, even when breaking changes happen.

I know that this process can be a hard path, but if some of the core foundations aren't change, we can wind up with a product that have some many exceptions and rules because of the backward compatibility need. - And for that unfortunate we have a lot not so good examples.

Take the Visual Studio Code edition for instance, it's the "breaking change" from the "big old backward compatible with 20 years of technology brother" right? Eventually the core of the VS Code will be the vNext of the product VS. Right? - at least it's what I'm hoping for.

[Shazwazza]

Thanks everyone for your input, help and review. I am accepting this RFC now as-is. We feel that this is the right strategy to move forward with .NET Core. There will be plenty more RFCs on this journey, this one is just the overview.