Riverside.Runtime 3.0.1

rvsx

The Riverside Standard.

The Riverside Standard (RVS) has been documented in lots of different places, with various different versions and lots of inconsistencies. This repo aims to unify them with a single standard with its own versioning system, the Riverside Standard Extended (RVSX).

The Riverside Standard consists of documentation, templates and libraries that demonstrate how to build a modern production app, and contains various utilities that aid in doing so.

Riverside.Standard

The Riverside.Standard class library contains helpers and classes that complement the actual Standard documentation itself and enforce it as a rich code analysis tool.

Riverside.Runtime

This class library contains various resources that enable the implementation of the Riverside Standard in an agnostic manner.

Riverside.Runtime.Modern

This class library targets WinUI3 and contains useful classes for building production apps using the latest technologies. It targets net8.0-windows10.0.19041.0.

Previous versions of the Riverside Standard had a different versioning system as they were dictated by supplemental convention; the River1 and River2 style conventions were very badly organised and their definitions were often stored in unexpected, internal documentation.

The first version of the Standard (River1) included requirements across everywhere - PRs, issues and commits were forced to have emoji appended to them; it had its own set of open source licenses; and most importantly versioning:

The River1 convention stated that each version should use the following format:

Major	.	Minor	.	Build No.	@	Channel
1	.	2	.	3	@	dev

The River2 convention (the second version of the Standard) was a bit more precise, but still with classic targets like emoji in commit names, issues, PRs and other places, but with a more professional outlook:

So instead, Esmerelda should use the new River2 convention, at which the following are determined:

• Each push to main triggers an automatic GitHub Actions/Azure Pipelines integration to build and publish a package to GitHub Releases as a prerelease.
• A branch protection rule is put in place to allow nobody to push directly to main except in emergencies, and therefore the technique named General Updates is used instead to manage this lifecycle, grouping individual small commits to a larger squashed commit/PR named a General Update, which has its own convention for naming schemes.
• There are only two channels which are pushed to, the release channel and the prerelease channel. The prerelease channel is automatically published to a Microsoft flight group on push to main and automatic creation of a prerealease in GitHub Releases.
• After careful review, the primary production channel which is seen on GitHub Releases and on the MPN/Storefront is published to automatically via a manually triggered GitHub Action cycle.
• This may change to automatic after a certain increment in build number, i.e. every 10 build number increments (every 10 commits)
• It should probably be in such a way as that every time the minor version is increased, the app publishes to the storefronts, so every 10 commits as aforementioned.

The River2 convention follows the following pattern:

Major	.	Minor	.	Build No.
1	.	2	.	3

Quoted text is taken from the Esmerelda Semantics spec, an internal specification on how Esme should (have) be(en) built to standard.

The 3rd version of RVS, called RVSX, provides a clean, understandable way to build high quality apps, far less cluttered than previous iterations.

Here's a short summary of the most important RVSX/3 analyzers. For all of them, browse the diagnostic analyzer source file.

RX00001 Projects must use a stable versioning system

RX00002 All projects must declare community health files

RX00003 Class libraries should be have Riverside Assembly declaration metadata

RX00004 Modern apps must derive their application definition from Riverside.Runtime.Modern.UnifiedApp

RX00005 All projects must use Riverside Toolkit and Runtime tools and helpers instead of declaring their own

RX00006 Projects must use Serilog for logging

RX00007 All related projects must be in a monorepo

RX00008 Projects must be localized using localization string resources if they are production ready

RX00009 All source files must explicitly define types

RX00010 All source files must be formatted cleanly to Riverside Standard code style

Please note that these annotations and specifically their identifiers are subject to strong change.