Pull Requests, Processes, Builds, & Roadmap

If you’ve been keeping up with the DNN Technology Advisory Group meeting replays then you know there was a very positive meeting that took place at DNN-Connect. Several action items stemmed from that meeting and I’ve been busy following up on them ever since. In this blog I’d like to communicate the status of some of the action items from that meeting with the greater DNN Community.

Community Drives Again!
The community driving again is the overarching theme to all of the following updates. We’ve previously mentioned this in meetings, blogs, and it was visually communicated by Daniel Mettler’s team in a poster they made for DNN-Connect. The reason I start off with this update is to reiterate the message that the change is real, the shift to the community driving is indeed happening and I want to ensure people hear and understand that message loud and clear. The following items are even more proof of the shift that is currently happening in our community.

And for any developers reading this… know that the below information is also communicated via GitHub as well. I am simply sharing a blog in hopes of greater transparency, reach, and consistency with communications.

RoadMap
The community is responsible for the roadmap of DNN Platform moving forward. More specifically the DNN TAG will collectively set the course for the platform. We will discuss needs, requirements, dates, and releases at DNN TAG meetings and will outwardly communicate that to the community. If you want to be involved in the roadmap or the DNN TAG simply reach out me or Clint Patterson and we will get you involved.

Release Schedule
Having consistent and well-communicated processes around releases is critical to the success of any software project. We don’t want anyone wondering when a release is coming and we want to standardize the steps/process included in a release in a way that allows time for testing of extensions and upgrades.

With that said we will have Release Candidates and Production Releases...

Release Candidates

• For a period of two-weeks (Minor & Revision) 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.
• The goal of these release candidates are 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.

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.
• 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.
• 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)
• Releases will not be completed during weeks of major holidays, specifically including 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.

Versioning
How releases are named can sometimes become a subject of passionate debate among software developers. Here again we want to standardize in this area as well so that the community knows what to expect and can anticipate the level of changes in a release based on the version name. Let’s look how the versioning details we can expect in the future:

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.

• The DNN Community adopted the current semantic version policy in July of 2018. Releases before this date may follow different standards.

• 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 change.
• Major releases are also the time that platform requirements might be changed, such as requiring a new edition of SQL Server or otherwise.

• 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.

• 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.

• 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 a 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, will be removed in y.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.

• Some legacy API's that do not have this style of commentary may not be removed at the next major release to ensure that the same communication protocol is followed.
• Each Major release will contain release notes outlining every API method removed.

Pull Request Process
The community is now empowered to make pull requests that will be first class citizens! We have a core group of reviewers from the community who will review and interact with all pull requests whether they come from the community or from ESW. Our team has been empowered to review, reject, and/or merge pull requests and hold everyone to the same standard across the board. We hope this will keep us from having broken builds in the future.

If you would like to submit a pull request be sure to include the following info:

• Issue Number: Every pull request should be associated with an issue number.
• Example:“Fixes issue #24”
• Release Note: We hope to ultimately include your pull request into the platform and as such the update will be rolled out in a future release. We want to communicate all updates to the community in the release notes so we need some context from you as to what your update does.
• Example: “Improvement of user profile to improve performance when searching”
• Testing Steps: To make life easier for our reviewers and ensure we are not unknowingly breaking things you should communicate the steps needed to test the validity of the change.
• Example:“Login as host, go to site management, add a new site. Site is added without error”

Code Review Process
Upon submitting a pull request our team will review the submission. Community review of submitted pull requests is encouraged, and all pull requests must be reviewed by at least 2 community approvers before the change can be approved. Once approved by two unique individuals the change can be merged by the secondary approval.

At the current time the following community members are designated approvers:

• Mitchel Sellers - DNN MVP & Technology Advisory Group Lead
• Ash Prasad - VP Engineering DNN Corp
• Brian Dukes - DNN MVP
• Oliver Hine - DNN MVP
• Daniel Mettler - DNN MVP
• Tomasz Pluskiewicz - CTO DNNCorp
• Vicenc Masanas - DNN MVP
• Erik van Ballegoij - DNN MVP
• Peter Donker - DNN MVP & Developer Advisory Group Lead

Individuals performing code review should validate, at a minimum, the following:

• The source should be able to be cloned, compiled, and all tests ran without error
• The issue identified should no longer be apparent, and testing steps validated
• The change should be free from visible errors, and adherence to recommended best practices should be validated.

If a reviewer has suggestions for improvement, those should be noted in the pull request and revision requested. If the pull request is acceptable “as is” simply noting, via a comment, “I reviewed this, no concerns” will document the completion of a review, this statement is preferred to the shorthand LGTM (Looks good to me).

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.

Approval & Merging Process
Once a pull request has been reviewed by two individuals it may be merged. It is important to note that this MUST NOT be done by the submitter of the pull request for ANY reason. In short, a reviewer cannot approve his/her pull request.

In Conclusion
I hope you read this blog with a “Wow, it’s really happening” sentiment because that’s the same feeling I had writing it. We are truly into a new phase of community and open source with DNN. I am very excited about this, but I am also well aware that with this new freedom comes much responsibility. If we are to thrive we must all step up, pitch in, and be leaders in our own respective areas of the community. If we do that then I have no doubt we will succeed!