mtrutledge · mtrutledge · Dec 18, 2020 · Oct 7, 2020 · Oct 7, 2020 · Oct 7, 2020
diff --git a/.editorconfig b/.editorconfig
@@ -4,8 +4,10 @@
 # top-most EditorConfig file
 root = true
 
+# Standardize on CR/LF (Windows) line endings
 # Don't use tabs for indentation.
 [*]
+end_of_line = crlf
 indent_style = space
 # (Please don't specify an indent_size here; that has too many unintended consequences.)
 
@@ -182,4 +184,4 @@ csharp_space_between_parentheses = false
 # Blocks are allowed
 csharp_prefer_braces = true:silent
 csharp_preserve_single_line_blocks = true
-csharp_preserve_single_line_statements = true
+csharp_preserve_single_line_statements = true
diff --git a/.github/BUILD.md b/.github/BUILD.md
@@ -49,7 +49,7 @@ You'll need to be running IIS and SQL server (Express) locally for this to work.
 The build process uses a local settings file which is excluded from source control so you won't accidentally upload this to Github. First open up Powershell at the root of this repository and run the following:
 
 ```
-.\Build.ps1 -Target CreateSettings
+.\Build.ps1 --target=CreateSettings
 ```
 
 This will create a file called `settings.local.json` at the root with the following content:
@@ -87,7 +87,7 @@ The settings are as follows:
 Once you've set up the above, run the following in Powershell:
 
 ```
-.\Build.ps1 -Target ResetDevSite
+.\Build.ps1 --target=ResetDevSite
 ```
 
 This will attempt to delete all content in `WebsitePath` and will build DNN to that location.
@@ -107,6 +107,7 @@ To build the .net projects to the right location, you'll need to create your ove
 ```
 
 Once you've created this file every time you click "rebuild" in Visual Studio on a project (or the solution) you'll see the content change in your dev site.
+**Note**: You may have to restart Visual Studio for this new build file to take effect.
 
 For the Webpack projects it is set up to read from the `settings.local.json` file and use the `WebsitePath` to copy generated js files to their right place.
 

diff --git a/.github/ISSUE_TEMPLATE/bug-report.md b/.github/ISSUE_TEMPLATE/bug-report.md
@@ -40,8 +40,8 @@ Provide any additional context that may be helpful in understanding and/or resol
 <!-- 
 Please add X in at least one of the boxes as appropriate. In order for an issue to be accepted, a developer needs to be able to reproduce the issue on a currently supported version. If you are looking for a workaround for an issue with an older version, please visit the forums at https://dnncommunity.org/forums
 -->
-* [ ] 10.00.00 alpha build (in development)
-* [ ] 09.06.01 latest supported release
+* [ ] 10.00.00 alpha build
+* [ ] 09.08.00 latest supported release
 
 ## Affected browser
 <!-- 

diff --git a/.github/PULL_REQUEST_PROCESS.md b/.github/PULL_REQUEST_PROCESS.md
@@ -25,18 +25,11 @@ Community review of submitted pull requests is encouraged, and all pull requests
 At the current time the following community members are designated approvers.
 
 * Mitchel Sellers ([mitchelsellers](https://github.com/mitchelsellers)) - Community Technology Advisory Group Lead
-* Oliver Hine ([ohine](https://github.com/ohine))
 * Brian Dukes ([bdukes](https://github.com/bdukes))
 * Peter Donker ([donker](https://github.com/donker)) - Community Developer Advisory Group Lead
 * Daniel Valadas ([valadas](https://github.com/valadas))
 * Matt Rutledge ([mtrutledge](https://github.com/mtrutledge))
-* Vicenç Masanas ([vmasanas](https://github.com/vmasanas))
-* Erik van Ballegoij ([erikvb](https://github.com/erikvb))
-
-Additionally, the following individuals from ESW/DNN Corp are approved reviewers.
-
-* Daniel Aguilera ([daguiler](https://github.com/daguiler)) - CTO
-* Ash Prasad ([ashishpd](https://github.com/ashishpd)) - VP of Engineering
+* David Poindexter ([david-poindexter](https://github.com/david-poindexter)) - Community Strategy Advisory Group Lead
 
 ### Review Minimums
 An individual performing the code review should validate at a minimum the following.
@@ -50,11 +43,17 @@ If a reviewer has suggestions for improvement, those should be noted in the pull
 
 *If you have questions about a pull request or an idea for a pull request, please reach out to one of the approvers before submitting to ensure a streamlined process.*
 
+### Draft PR's
+For proper management of pull requests the team will utilize the "Draft" option within a pull request to identify something that is being submitted for consideration and in need of review/comment or other special review from the team.  Individuals should coordinate with the Approvers group prior to submitting any Draft pull requests as they are special cases.
+
+### On-Hold Tag
+The Approvers group will add the "On-Hold" tag to any pull request that is targeting a major or minor release until it is ready for merging.  This is done as an administrative process to prevent accidental merging and is not a reflection of rejection of the submitted code. The associated milestone will be updated when the "On-Hold" tag has been added for clear communication regarding expectations.
+
+Examples of requests of this nature include technology or dependency changes that could introduce major/minor breaking changes.
+
 ## Merging & Closing of Requests
 Once a pull request has been reviewed by two designated approvers it may be merged and the pull request closed.
 
-> This **_MUST NOT_** be done by the submitter of the Pull Request for ANY reason!  
-
 ### Execption for Build Process Pull Requests
 A special exception has been granted to reduce the number of Designed Approval reviews to 1 for all pull requests related to Build Support when incrementing versions in prepration of a release, or reconfiguration of the environment for the next version. 
 
@@ -68,10 +67,3 @@ We follow the process outlined in the [Versioning Policy](VERSIONING_POLICY.md)
 The review team will work to respond to all pull requests in a timely fashion.  If changes or additional information is requested a pull request will remain open allowing the submitter to update their contribution accordingly.  If a request for additional information or changes is not completed with 90 days of request the Pull Request will be closed to keep the pipeline clear.  Once the needed information has been gathered the information can be re-submitted via a new Pull Request.  
 
 For expedited processing you may reference the prior Pull Request.
-
-### Items for Future Releases
-If an item was submitted that will be integrated into a future release that is not currently in the development pipeline it is possible that the Pull Request will remain open. 
-
-In this situation the reviewing team will approve the request, tag the request with a specific version milestone and add a comment noting when and why it will be included in the particularly identified release.
-
-This most often will apply to technology or dependency changes that require alignment with Major, Minor, Revision build inclusion.  
diff --git a/.github/RELEASE_SCHEDULE.md b/.github/RELEASE_SCHEDULE.md
@@ -1,16 +1,29 @@
 # DNN Platform Release Schedule
-To ensure adequate time for release planning by the community, partners, and vendors a specific release process will be followed for all releases.  
+To ensure adequate time for release planning by the community, partners, and vendors, a specific release process will be followed for all releases.  
 
 ## Release Candidates
-For a period of one week (Revision), two weeks (Minor) or four-weeks (Major) before any release, a Release Candidate (RC) version will be made available to the public.  At present these release candidates will be for testing only. After version 10.x efforts will be made to support upgrading from RC to Production releases.
+A Release Candidate (RC) is designed to give the community time to adjust their existing environments for any breaking changes and identify any unintended changes. Strong community participation during the RC process will result in more stable releases. 
 
-The goal of these release candidates is to give the community time to adjust their existing environments for any breaking changes, as well as to identify any issues with the changes.  If necessary, changes will be incorporated an additional RC release could be made if significant problems are identified.  If a revised Release Candidate is necessary the Production Release schedule will be impacted.  The exact impact will vary on a case-by-case basis depending on the nature of the issue(s) identified during RC review, however, will be clearly communicated during the release.
+### Major Releases (`MAJOR.Minor.Patch`)
+Major releases will have an initial RC cycle with a minimum duration of three weeks between the date of the RC release and the date of the final release. 
 
-## Production Releases
-Production releases will only be completed after a successful RC phase, except in the case of a significant security release that was included as part of a revision release.
+### Minor Releases (`Major.MINOR.Patch`)
+Minor releases will have an initial RC cycle with a minimum duration of two weeks between the date of the RC release and the date of the final release.
 
-The release date will be communicated to the community at the time of the RC.  And each release will take the following considerations into mind for all releases.
+### Patch Releases (`Major.Minor.PATCH`)
+Patch releases will have an initial RC cycle with a minimum duration of one week from the RC release and final release.
 
-* Releases must allow for at least two additional business days after the release for regular Monday - Friday office situations (Releases only on Monday, Tuesday or Wednesday)
+### Changes During RC Cycle
+If necessary, changes will be incorporated during an RC; if the changes resolve significant issues or introduce risk, an additional RC may be created at the discretion of the Approvers group.  If a revised RC is necessary, the Production Release schedule will be impacted; the exact impact will vary on a case-by-case basis depending on the nature of the issue(s) identified during the RC review. However, it will be communicated as part of the updated RC release notes.
+
+## Final Releases
+Production Releases will only be completed after a successful Release Candidate cycle, except in the case of a significant security release included as part of a Patch release.
+
+The anticipated release date will be communicated to the community at the time of the RC.  And each release will take the following considerations into mind for all releases.
+
+* Releases must allow for at least two business days following the release (based on standard business operations of Monday - Friday). Thus, releases should only be made on Mondays, Tuesdays, or Wednesdays.
 * Releases will not be completed during weeks of major US holidays, specifically New Years, Memorial Day, Independence Day, Labor Day, Thanksgiving Day, or Christmas.
 * Best efforts shall be made to avoid other significant holidays in other countries.
+
+## Release Notifications
+You can utilize the "Watch" functionality within GitHub to receive notifications for new Release Candidates and Production Releases using the "Releases Only" notification option.
diff --git a/.github/VERSIONING_POLICY.md b/.github/VERSIONING_POLICY.md
@@ -1,29 +1,33 @@
 # DNN Platform Versioning and Deprecation Policies
 The DNN Platform follows a semantic versioning process for releases, in a manner to better communicate expectations of releases and their potential impacts to users of the platform.
 
-##Semantic Versioning
+## Semantic Versioning
 The DNN Community adopted the current semantic version policy in July of 2018.  Releases before this date may follow different standards.
 
 ### Major Releases (Ex 10.0.0)
 A major release is as the name implies, a release with major changes.  These changes might include new features, breaking changes, or other larger changes.  Each major release will come with release notes that outline the nature of any known breaking changes.
 
-Major releases are also the time that platform requirements might be changed, such as requiring a new edition of SQL Server or otherwise.
+Major releases are also the time that platform requirements might be changed, such as requiring a new edition of SQL Server, .NET Framework, or otherwise.
 
 ### Minor Releases (Ex 10.1, 10.2, 10.x)
-A minor might contain smaller new features and enhancements, but will not introduce any breaking API changes, nor will it change the requirements of the hosting environment or platform to run the application.  
+A minor release might contain smaller new features and enhancements, but will not introduce any known breaking API changes, nor will it change the requirements of the hosting environment or platform to run the application.  
+
+It is possible that minor breaking changes and Javascript library updates are included in minor releases.
 
 ### Revision Releases (Ex 10.1.1, 10.1.2, 10.1.x)
-These releases are created primarily to contain hot-fix style improvements from prior releases.  Any bugs or security issues identified, or missing UI/UX features from a Minor/Major release might be added to a revision release.  Similar to a Minor release a Revision release will not contain any known breaking changes.
+These releases are created primarily to contain hot-fix style improvements from prior releases.  Any bugs or security issues identified, or missing UI/UX features from a Minor/Major release might be added to a revision release.  Similar to a Minor release a Revision release will not contain any known breaking changes API.
+
+## API Deprecation Policy (Updated September 2020)
+The DNN Platform project is in a state of transition, continuing to modernize the API and remove existing technology debt.  To this point, it will be necessary for the project to remove/restructuree many public API's.  This will be done methodically, allowing developers to transition away from the older code with time to properly respond to change.
 
-## API Deprecation Policy
-The DNN Platform project is in a state of transition, continuing to modernize the API and work towards a transition to .NET Core.  To this point, it will be necessary for the project to remove public API's.  This will be done methodically, allowing developers to transition away from the older code with time to properly respond to change.
-Any API method to be removed will be flagged as deprecated in a release, major, minor or revision, and will be identified to be removed by a specific version.  This will be done using a C# annotation with a comment similar to the following "Deprecated in x.x.x.  Scheduled for removal in vy.0.0, use ____ instead".  The version number of "y" in this example must be 2 major versions ahead.  
-Therefore, an API marked as Deprecated in 9.2.1 can only be removed in version 11.0.  Additionally, methods marked for removal in a version will GUARANTEED be removed in that revision.
+Any API method to be removed will be flagged as deprecated in a release, major, minor or revision, and will be identified to be removed by a specific version.  This will be done using a C# `[Obsolete]` attribute with a comment similar to the following "Deprecated in x.x.x.  Scheduled for removal in vy.0.0, use ____ instead".  The version number of "y" in this example must be 1 major versions ahead of the version in which the notice was added.
+
+Therefore, an API marked as Deprecated in 9.2.1 can only be removed in version 10.0.  Additionally, methods marked for removal in a version will GUARANTEED be removed in that revision.
 > Example: [Obsolete("Deprecated in DotNetNuke 7.0. This function has been replaced by AddUserRole with additional params. Scheduled removal in v10.0.0.")]
 
+### Testing Recommendations
+It is suggested that all extension developers recompile their projects on the latest API versions on a regular basis to identify removed elements as the compiler warnings will be the primary communication method for these changes.
+
 ### Special DNN 10.x Cleanup
 A number of legacy APIs have been marked as deprecated for more than 7 years and not yet removed.  To continue to clean the API structure a final cleanup is being completed as part of the 10.x release.  All of these API's are more than 2 major revisions older, however, have non-standard indicators for the Obsolete attribute.  These will be removed in 10.x along with other expected removals.
 Lastly, each Major release will contain release notes outlining every API method removed.  More information can be found [in this blog post](https://www.dnnsoftware.com/community-blog/cid/156712/moving-forward-dnn-platform-100-growing-pains-lead-to-improvement)
-
-
-
diff --git a/.github/images/PoweredByNDepend.png b/.github/images/PoweredByNDepend.png
diff --git a/.github/mergeable.yml b/.github/mergeable.yml
@@ -6,7 +6,15 @@ mergeable:
         no_empty:
           enabled: true # Cannot be empty when true.
           message: 'A milestone must be assigned to this pull request'
+        must_exclude:
+          regex: 'Future:'
+          regex_flag: 'none'
+          message: 'A milestone that does not contain `Future:` must be assigned to this pull request'
       - do: label
         begins_with:
           match: 'Type:' # or array of strings
           message: 'A `Type:` label must be assigned to this pull request'
+        must_exclude:
+          regex: 'On Hold'
+          regex_flag: 'none' # Optional. Specify the flag for Regex. default is 'i', to disable default use 'none'
+          message: 'This PR is `On Hold`'
diff --git a/.gitignore b/.gitignore
@@ -114,6 +114,8 @@ DNN [Pp]latform/Syndication/[Bb]in/*
 DNN [Pp]latform/[Cc]onnectors/*/[Bb]in/*
 DNN [Pp]latform/[Pp]roviders/*/[Bb]in/*
 
+DNN [Pp]latform/Modules/ResourceManager/**/scripts/*-bundle.*
+
 # ignore all other language resx files
 *.de-DE.resx
 *.es-ES.resx
@@ -130,3 +132,9 @@ DNN [Pp]latform/[Pp]roviders/*/[Bb]in/*
 
 # Add fips back
 !DNN Platform/[Ww]ebsite/App_Data/FipsCompilanceAssemblies/Lucene.Net.dll
+
+yarn-error.log
+
+/Build/bin/
+/.dotnet/
+/Build/Tools/
diff --git a/Build/Build.csproj b/Build/Build.csproj
@@ -0,0 +1,19 @@
+<Project Sdk="Microsoft.NET.Sdk">
+  <PropertyGroup>
+    <OutputType>Exe</OutputType>
+    <TargetFramework>net4.8</TargetFramework>
+    <PackAsTool>true</PackAsTool>
+    <!-- Make sure start same folder .NET Core CLI and Visual Studio -->
+    <RunWorkingDirectory>$(MSBuildProjectDirectory)</RunWorkingDirectory>
+  </PropertyGroup>
+  <ItemGroup>
+    <PackageReference Include="Cake.FileHelpers" Version="3.3.0" />
+    <PackageReference Include="Cake.Frosting" Version="1.0.0-rc0001" />
+    <PackageReference Include="Cake.Git" Version="0.22.0" />
+    <PackageReference Include="Cake.NuGet" Version="1.0.0-rc0001" />
+    <PackageReference Include="Cake.XdtTransform" Version="0.18.1" />
+    <PackageReference Include="Dnn.CakeUtils" Version="1.1.10" />
+    <PackageReference Include="Newtonsoft.Json" Version="12.0.3" />
+    <PackageReference Include="System.Data.SqlClient" Version="4.8.2" />
+  </ItemGroup>
+</Project>
diff --git a/Build/Build.sln b/Build/Build.sln
@@ -0,0 +1,25 @@
+
+Microsoft Visual Studio Solution File, Format Version 12.00
+# Visual Studio Version 16
+VisualStudioVersion = 16.0.30717.126
+MinimumVisualStudioVersion = 10.0.40219.1
+Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = "Build", "Build.csproj", "{0E12A49C-A8A3-43E4-A25B-6E6F51DD7D14}"
+EndProject
+Global
+	GlobalSection(SolutionConfigurationPlatforms) = preSolution
+		Debug|Any CPU = Debug|Any CPU
+		Release|Any CPU = Release|Any CPU
+	EndGlobalSection
+	GlobalSection(ProjectConfigurationPlatforms) = postSolution
+		{0E12A49C-A8A3-43E4-A25B-6E6F51DD7D14}.Debug|Any CPU.ActiveCfg = Debug|Any CPU
+		{0E12A49C-A8A3-43E4-A25B-6E6F51DD7D14}.Debug|Any CPU.Build.0 = Debug|Any CPU
+		{0E12A49C-A8A3-43E4-A25B-6E6F51DD7D14}.Release|Any CPU.ActiveCfg = Release|Any CPU
+		{0E12A49C-A8A3-43E4-A25B-6E6F51DD7D14}.Release|Any CPU.Build.0 = Release|Any CPU
+	EndGlobalSection
+	GlobalSection(SolutionProperties) = preSolution
+		HideSolutionNode = FALSE
+	EndGlobalSection
+	GlobalSection(ExtensibilityGlobals) = postSolution
+		SolutionGuid = {13A32835-854D-40B7-B497-882B55297419}
+	EndGlobalSection
+EndGlobal