Andy,
my comments are below in red - i also have a list longer than 1 item, and have been sending mails and creating issue's approriately. I'm sure we'll have a meeting soon to triage the issues, and arrange updated release(s)
Andy Schmidt wrote
Hi Cathal:
I went back through the last 4 days of reports, replies, logged issues and I've come up with a list that much more than just 1 packaging error and (expected) issues with 3rd party modules).
Hope this list helps focusing everyone's attention to avoid having another repeat...
http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=8716&PROJID=2
Two part problem:
a) moving DotNetNuke.FckHtmlEditorProvider.dll from bin/providers to bin
b) need to bundle the latest FCK Editor which is stuck in the tracker
this is not a 2 part problem - the first part is the issue, and is a packaging problem - the 2nd one is a reference that a module that has passed through the project release tracker should have been bundled (you can track it@ http://www.dotnetnuke.com/Products/Development/ProjectReleaseTracking/tabid/997/ctl/History/mid/3337/ItemID/345/Default.aspx ) - this is at the release manager's discretion. In this case, I would have expected it to be bundled, but my guess is that the corp did not have the time/resources to complete the process and hence it wasn't bundled.
http://support.dotnetnuke.com/issue/ViewIssue.aspx?id=9025&PROJID=2
PortAlias(es).ascx
Library\Services\Upgrade lines 2513 to 2518 are wrong..
AddModuleControl(ModuleDefID,"", "", "DesktopModules/Admin/PortalAliases/PortalAlias.ascx", "", SecurityAccessLevel.Host, 0)
I believe the intent here was to have the content moved to an alternative place to allow this particular menu item to be shared out to non-admin users. It appears that the code and it's declaration are out of sync - it'll take a while to establish the correct permutation.
http://support.dotnetnuke.com/issue/ViewIssue.aspx?ID=9038&PROJID=2
Users Online Broken (Caching Issue)
this is an issue new to 4.9.1/5.0 - it'll be validated and including in the next release I'm sure (the issue was only created today)
http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/-1/threadid/276697/scope/posts/Default.aspx
Possibly WRONG version of Auth Provider included with 5.0
this appears to be a bundling issue - 5.0 needs the updated version - more detail below.
http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/-1/threadid/275089/scope/posts/Default.aspx
Legacy Skins don't install under 5.0
this appears to affect only some skins. It appears that some were using incorrectly cased attributes, and that 5.0 now requires correct casing. I suspect this will be reverted to support legacy skins depending on an unintended side-effect. There may be other permutations, it'll take a while to work through.
To be honest, what I find hard to accept are things like issue 8716. It's been open since 11/8/2008, logged as a "Show Stopper", but apparently show stoppers don't prevent a release 7 weeks later? As a new DNNer I'm also puzzled by FREQUENT mentions of contributors that their REQUIRED/NECESSARY updates are "stuck in the tracker", apparently for weeks and months - and then they are forgotten from the release? I can't figure how any "release process" can not first check whether all "show stoppers" are resolved AND the whatever is pending in "tracker" is unstuck!?
Best Regards,
Andy
Andy,
as you're new, you're probably not aware of a few things, that might explain some of the confusing issues (and perhaps help any others new to the commnity)
- project releases are seperate from core releases - we decoupled them a number of years ago. This means that projects can be released independantly of core releases. It's perfectly normal to have projects in the release tracker that are not included in a core release.
- on occasion a project will require an update to be syncronised with a core release -this appears to be the case with the auth provider - there was clearly a breakdown in communication somewhere to organise this as the release manager took the latest released versions of projects when doing the bundling.
- theres a long-standing frustration from many project team leads on the time taken for a project to go through the tracker -some of this is because the additional stages such as xhtml validation, security audits etc. add an overhead, but mostly it's because the final stages of dogfooding and distributing can only be done by a limited set of people who are pushed for time. One of our hopes is that now the corp has funding, this delay will disappear i.e. there will be a resource available to do this in a timely fashion.
- we have 7 internal betas, and 2 release candidates for cambrian. There are plenty of items that were created during this period that are no longer issues - this issue was not a release in a number of these for instance. 8716 is a bundling issue, not a code issue. For those of us syncronised with the source code it was never an issue (the file existed in both locations AFAIR) - it only manifested in some builds if installed was done from the build.
Historically we've used major version increments to indicate when theres been a lot of change to dotnetnuke, and in the past there has been a lot of issues with those builds (anyone from the 2.0 and 3.0 days will remember this). To try and avert some of this cambrian was made available to a very large testing group, first internally , then to sponsors, then in october (http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryId/2010/DotNetNuke-5-0-RC1.aspx to a much larger audience), then finally to the public (http://www.dotnetnuke.com/Community/Blogs/tabid/825/EntryId/2076/DotNetNuke-5-0-0-RC2-available-for-download.aspx) . This has helped a lot , but obviously bugs still creep in (though if issues do turn out to involve bundling we need to work on our build server processes).
Cathal