Riverside.Runtime.Modern
3.0.0
dotnet add package Riverside.Runtime.Modern --version 3.0.0
NuGet\Install-Package Riverside.Runtime.Modern -Version 3.0.0
<PackageReference Include="Riverside.Runtime.Modern" Version="3.0.0" />
paket add Riverside.Runtime.Modern --version 3.0.0
#r "nuget: Riverside.Runtime.Modern, 3.0.0"
// Install Riverside.Runtime.Modern as a Cake Addin #addin nuget:?package=Riverside.Runtime.Modern&version=3.0.0 // Install Riverside.Runtime.Modern as a Cake Tool #tool nuget:?package=Riverside.Runtime.Modern&version=3.0.0
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 theprerelease
channel. The prerelease channel is automatically published to a Microsoft flight group on push tomain
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.
Product | Versions Compatible and additional computed target framework versions. |
---|---|
.NET | net8.0-windows10.0.19041 is compatible. |
-
net8.0-windows10.0.19041
- Microsoft.Windows.SDK.BuildTools (>= 10.0.26100.1742)
- Microsoft.WindowsAppSDK (>= 1.6.241114003)
- Riverside.Runtime (>= 3.0.0)
- System.CommandLine (>= 2.0.0-beta4.22272.1)
- System.CommandLine.NamingConventionBinder (>= 2.0.0-beta4.22272.1)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
Version | Downloads | Last updated |
---|---|---|
3.0.0 | 4 | 11/23/2024 |