Products

Solutions

Learn More

Partners

Community

Blog

About

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.


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 DNN Community Pics from 2018 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
DNN 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
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.
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 change.
  • Major releases are also the time that platform requirements might be changed, such as requiring a new edition of SQL Server 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.
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.
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 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.
** NOTE **
  • 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
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
Code Review 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!

Comments

Clint Patterson
Great stuff Mitchel - thanks for sharing this info!
Clint Patterson Thursday, June 14, 2018 12:18 PM (link)

Comment Form

Only registered users may post comments.

NewsArchives


Aderson Oliveira (20)
Alec Whittington (11)
Alessandra Davies (1)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (36)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (212)
Chris Paterra (55)
Clint Patterson (89)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (165)
Daniel Valadas (6)
Dave Buckner (2)
David Poindexter (10)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (79)
Francisco Perez Andres (8)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (3)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (1)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (32)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott S (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (81)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Timo Breumelhof (24)
Tony Henrich (3)
Torsten Weggen (2)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (171)
William Severance (5)

Content Layout

Subscribe to DNN Digest

Subscribe to DNN Digest

DNN Digest is our monthly email newsletter. It highlights news and content from around the DNN ecosystem, such as new modules and themes, messages from leadership, blog posts and notable tweets. Keep your finger on the pulse of the ecosystem by subscribing.  

What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out