DNN Road map update

[soheilkheiri]

Hello

Please specify a roadmap for DNN 9.7.x and later

[mitchelsellers]

We are adjusting the way that we communicate the roadmap and other elements to be more realistic in the process.

David Poindexter recently created this blog about the topic

[soheilkheiri]

We want to plan for an extensive update and we need the right timing.

Please specify a date & time for next releases

[mitchelsellers]

I apologize for my initial short response here, I think this is worth putting just a bit more effort/detail to.

As an open-source project, we do not have any budget nor do we have any dedicated resources. We receive contributions as people have the time, and energy to commit them. We group these into releases as it makes sense, for example 9.7.0 was created due to a number of new features, and subsequent 9.7.1 and 9.7.2 releases for quick bug fixes.

We are working towards a 9.8.0 release with a new file manager and optional Telerik removal, but we cannot commit to the date as it will depend on when we get issue resolution.

We used to communicate dates, but then when those slipped we were criticized for not meeting goals. The revised process, as outlined in the linked post, is our best efforts to be able to bridge the needs/requirements.

[wbonekamp]

Maybe it's a plan to involve the most commonly used vendors like Dnnsharp, Mandeeps, Easydnn in this proces.
Because of the deprecated methods we have a lot of upgrade issues with third party modules not being compatible with the latest version of DNN.

Maybe these vendors can do the first testing and make sure their modules are compatible as soon a the nest DNN upgrade is released officially.

I'm sure this will prevent a lot of frustration when upgrading to the latest version of DNN.

But as a result DNN is secure, stable and fast! We really appreciate that!

[mitchelsellers]

We invite everyone to test every release and have set schedules for the duration of those tests. With abilities for any individual to receive notifications the second we post.

We strive to keep breaking changes now to major releases, but it isn’t always the case.

Vendor testing is a critical pathway to our success. Some actively participate some do not. But we want them all to.

[ohine]

We invite everyone to test every release and have set schedules for the duration of those tests. With abilities for any individual to receive notifications the second we post.

@mitchelsellers Any plans to revert back to the 2-week RC testing window? It seems like that policy was reduced to just 1 week for the majority of builds (minor releases) and asking vendors to drop everything and return test results for their modules in less than 1 week seems nearly impossible.

I know our clients need a concrete schedule, which is adhered to, so they can schedule QA testers and developers.

972 rc to final: 10 days.
971 rc to final: 10 days. Friday final release. Release policy violation.
970 rc to final: 30 days.
962 rc to final: 12 days.
961 rc to final: 7 days.
950 rc to final: 14 days.

In addition, it looks like one recent build was released on a Friday which is also a violation of the release policy.

[valadas]

9.7.1 was not released on a Friday @ohine

In your table above

• no patch release was shorter than 1 week
• no minor release was shorter than 2 weeks
• no major release was shorter than 4 weeks

Patch releases are our way to act fast on reported issues, I think those deserve more of a quick cycle than a long one IMO. We are now much quicker on our feet to react to regression issues and it has been a couple of times when some non-expected breaking change has been addressed in a patch release within days or hours and I believe that was appreciated by those affected.

[mitchelsellers]

What @valadas said for the most part.

We moved to 1 week due to multiple releases with no feedback during the second week, and an effort to move the project forward more quickly.