-
Uno Platform
Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.
-
Umbraco
Umbraco is a free and open source .NET content management system helping you deliver delightful digital experiences.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
Why is this a problem? At face value, it isn't a problem. Taking a step back at a more global level, what does "uComponents" mean to the rest of the world? Many of the .NET developers who heavily use NuGet may have not even heard of Umbraco CMS, let alone a 3rd party plugin for it. What if people from the Uno Platform community are browsing NuGet for some kind of components extension library? You can see, this could get confusing outside the scope of the Umbraco community/ecosystem. On top of this, uComponents was developed against Umbraco v4, with its last release in 2016, now it's there to be lingering on the NuGet repository until the end of time, set in stone.
Nowadays, especially for any Umbraco extensions I develop, I try to follow Umbraco's own namespaces as closely as possible. e.g. I'd put my custom IContentFinder classes under a [Brand].Web.Routing namespace. Mostly so that it feels logical for any other developers who may be familiar with Umbraco core code.
Code Guide by Mark Otto, Standards for developing consistent, flexible, and sustainable HTML and CSS.
For something that is more short-lived, such as a pre-launch content migration using uSync Migrations, that may require custom code, I'd have a standalone [Brand].Cms.ContentMigration library, so that it can easily be removed prior to launch/production.
My reasoning behind this, is for GitHub's approach to repository forking. Let's take for example Umbraco's RFCs repo, umbraco/rfcs; the name of the organisation is umbraco and the name of the repository is rfcs, (all makes sense!). If I were to fork this repo, (which I have), then that would become leekelleher/rfcs, losing it's context of it being about Umbraco - so I'd personally rename my fork to leekelleher/umbraco-rfcs.
My reasoning behind this, is for GitHub's approach to repository forking. Let's take for example Umbraco's RFCs repo, umbraco/rfcs; the name of the organisation is umbraco and the name of the repository is rfcs, (all makes sense!). If I were to fork this repo, (which I have), then that would become leekelleher/rfcs, losing it's context of it being about Umbraco - so I'd personally rename my fork to leekelleher/umbraco-rfcs.