Re: DotNetNuke Core Release Process

I'm glad your taking your time. The biggest problem with most software packages is the lack of resources for RC testing. Almost all projects, especially in the open source realm, rely on the user base to find bugs AFTER its been released. Few projects ever see this level of maturity from their developers. While the Tech Geek in me is disappointed that 4.5 isn't out yet as a business owner I'm relieved I'm not the guinea pig.

Re: DotNetNuke Core Release Process

I hate to quote a cliché, but so say all of us. Well done team for sticking to your guns, quality is what matters for sure. DNN has now hit a crucial point in the development cycle; I believe this is a historic point where the project is clearly on the edge of maturity, congratulations in advance. I believe this is the point where it all comes of age; IT journalists take note.

Re: DotNetNuke Core Release Process

Great stuff. Thanks for the explanation of the process and we are stoked the team is so concerned with getting it right. We'll keep waiting excitedly and get the release a soon as its available.

Re: DotNetNuke Core Release Process

thanks for the update

Re: DotNetNuke Core Release Process

I think your technique works well, for those that want or need to access the version well in advance they can join the program (that also helps fund DNN) and for those that simply want a stable platform to utilise (me) I am happy to leave you guys to fix for a week while i can keep working on my modules. Keep giving us dates about future releases, it is great for planning, but hey I'd rather you miss them and sort out bugs. Don't let any critism stop you from posting possible dates.

Re: DotNetNuke Core Release Process

I agree that the process is good, but I think there is a lesson to be learned here: the announced release date for 4.5 was only 2 weeks behind the announced RC1 date for Platinum Benefactors. I'm not sure it is realistic to assume that 2 weeks will be enough time to beta-test a release. In this case, it took several iterations of the process to get to a stable release, and I think that possibility should be planned for.

So, if you are going to announce a release date, make it at least 4 weeks after the RC, to be safe. You can always ship early, if things go surprisingly well.

Re: DotNetNuke Core Release Process

As with other correspondents, I'm keen to get the 4.5 release - particularly as it 'empowers' AJAX. [A terrific ASP extension].
As with others, I rely on the stability of this platform for my business, so waiting until your internal quality checks are done is great news.
One last point. Do you work through defined test scripts? or is it a case of relying on your premium partners?

Re: DotNetNuke Core Release Process

This is a tough issue for any open source project. It comes down to the lesser of two evils. I believe it is better to get information into the hands of the community and miss a release date than it is to keep quiet until the release is completely finished. News regarding upcoming features are a great help in planning on our end. Thanks for all of your efforts!

Re: DotNetNuke Core Release Process

I think everyone is doing a great job and I'm very happy that you are not pushing this release out early. Another approach that could be taken would be to do as you are doing, ie. releasing a few RC builds to the Platinum folks, but instead of releasing a hard release to the public after the RC's, why don't you release one more RC to the public for a period of 1 or 2 weeks to get those final bugs spotted. I know the Platinum folks do a very good job in catching a lot of bugs but I think a more widespread beta at the end of the release cycle would make the releases even more rock solid. In the past we've had a few releases that are followed up very closely with another point release and then we get users who are stuck with the first release and because it's a full release we're obligated to continue supporting it. Do you think this approach is feasible?

Re: DotNetNuke Core Release Process

Well, I'm sorry to disagree. I sure love DNN and I'm very grateful of the core team's effort to deliver such a wonderful tool free to the community. But I don't think we need to be condescending about it. Despite the fact that the software industry got used to being frivolous about release dates, this is not the way things should be. You say that release dates have been [reluctantly] announced so that we - developers - could plan. Well, that's what I did, and it didn't work too well for me. Anyway, I don't intend to be hard on you, and -- by any means -- to belittle the importance and difficulty of your work. But I think that "sorry, we're late, we apologize for any inconvenince" is preferrable to the lousy BS "you know how it is, software is hard and umpredictable, we're doing our best, we don't want to deliver untested or buggy product..." Yeah, right.
Keep up the good work, we're counting on you! (and counting the days to the new release)

Re: DotNetNuke Core Release Process

Joe: Probably this is not the right way to reach you, but take this as a personal comment, not aimed to blog publication. My previous comments were more directed to the community than to the Team. We all sure love you, but if we keep being that condescending, you'll become lazy ;-) I sure have a contingency plan -- if I didn't I shouldn't consider myself a professional developer. Problem is I have two brand new portals to install at a brand new ISP, and I'm delaying installation till 4.5 (I don't want to install and then have to upgrade 1 week later). It all has to be up and running next monday, so I'll spend my week-end setting it all up with 4.4.1. This would be funnier if I was installing 4.5, and could have been done at working hours if I was not counting (or better, hoping) to get 4.5 till today. But, as you see, no big damage here.
I think you got my point. I too work with CMMi, PSP and TSP, and we know that for small to medium-size businesses this is an elusive target. But I make my better efforts to deliver on time, and when I don't i don't expect any condescendence from my customers. Well, you deserve better than me, so thanks for your very kind reply.

Re: DotNetNuke Core Release Process

Software release dates are expected in any software company.. however, it does not say anywhere it is a guarantee. If DotNetNuke wants to be in the corporate environment, then it too must stick to the world of dates (in the planning sense). Don't forget quality before quantity and nobody should complain. I do think a focus on still lingering issues should have some (but not all) concentration of effort over continual new functionality. Thanks.

Re: DotNetNuke Core Release Process

I am just getting around to understanding the development environment that is DNN however I am certainly not new to engineering, software development etc. especially in the PC/Video gaming industry.

In the case of DNN deployment of new release candidates it is imperative that proper time be taken to make certain that no serious bugs are introduced and that upgrading to the new release for DNN users is not problem prone. There is nothing more frustrating than performing a upgrade and said upgrade damages the end users (in this case webs) to become disfunctional.

In video gaming development (which often represents the cutting edge of software development) rigorous testing occurs before commercial release. With the myriad of computer configurations and software mounted on end consumers systems patches are almost a certainty after a release. Development houses gear to expect this. After all, if an end consumer drops $50 clams on a game and rapid support does not come forth (and I mean rapid) it goes back to the store resulting in complete loss of that sale.

Normally with what open source projects I have dealt with (Mambo/Joomla and a few others) support after a release often comes from the third party development community. Most webmasters would much prefer the core team take the time to release when its really ready thus when they upgrade its painless and a good experience for them and their site users.

With the number of deployed DNN sites I would assume that the number of the beta sites is significant. If not, then this might be something to consider. Portals operated by developers as beta leads so problems can be properly documented, researched and reported.

A "wish" I would like to see for DNN pertinent to exceptions would be when a critical exception occurs the host/admin can instantly see in perhaps a pop-up the details.

Additionally I would like to put forward that the DNN core really need try and rate third party developers by some form of standard. We purchased a module for forms from Snow Covered. While setting the forms up was not too difficult when it comes to getting a report from the form submissions to our amaze it looks like the product is completely unfinished (and of course did not work). The developer seems to care less responding to inquiries with one line emails.

While I think most folks setting up with DNN understand third parties it does not mean that those folks get a good feeling. In other words, such parties reflect on the third party development community in a negative way. Thus when a prospective module buyer goes shopping they are far far more weary to do so. This ultimately impacts the good 3P's ability to vend modules to the DNN community. When the 3P community is impacted ultimately DNN is as well. I might suggest some form of licensed or certified developers. That is to say, certified developers agree to proper support, professionalism and adhere to the DNN core development standards. This at least gives the end module consumer a gauge. From what I can see of the module we purchased its simply been glued together from DNN release to release and the developer (Cox) could care less. Unfortunately we did not read the "ratings" at SnowCovered before the purchase. But at I noted it reflects on the 3P development community and it is this community that ultimately are making extensions to DNN that break much new ground for the software. How many prospect DNN sites (webmasters) get turned off completely due to purchases of modules from 3P's that reflect poorly on the 3P dev community? How many of those webmasters do not make the logical seperation of core vs 3P vs DNN's prospects for them as webmasters? I'd wager to say its significant. So perhaps some food for thought...

Perhaps the core can consider a certified vs not developer community, standards as well as qualification. I am planning on doing development for DNN as I come up to speed. In open source projects where many 3P's engage in development these sorts of issues are never addressed and most assuredly impact the "good" (being the product DNN, the good 3P dev's who loose consumer faith and ultimately the end webmasters in this case). Perhaps for a developer/modules to be "certified" they could be sent to various sites (freely) where they would be run through their paces. If all goes well, certified. If not, the developer needs to meet the standards.

Its a difficult issue to consider. Does the development community get stifled by such measures? Perhaps the DNN core should consider what/who is most important in the work. The end webmasters/hosts? The developers? DNN itself? Again, I put this out there due to our recent experience. Being a coder I understand that 3P purchase is a gamble. However, for those not so enlightened I can guarantee the effect is a mistrust of 3P modules resulting in a negative impact on good 3P's work which ultimately comes full circle to DNN. If those 3P's loose prospect clients to their work will they continue to develop for DNN etc. Its a mess.

I look forward to the 4.5 release and your consideration of my statements.

Re: DotNetNuke Core Release Process

Of additional note as I was just reminded by my other half. New core releases are wonderful... However, a portal we are working on for example really needs the "Events Module" which does not work with 4.4.1. Since we expect significant traffic to the portal we decided to go with 4.4.1 due to the vast increase in efficiency born of Net 2.0 and I assume VS 2005. For that matter, we'd assumed that modules listed as core on the site would work with the nee release albeit maybe with a few glitches as modules got soothed in.

The events module last update at SourceForge was 3/2006, a wee bit over a year ago. I wish I presently had the DNN skill set to just say, "okie doke, I'll work on it and make it work" but I am a noob to the development framework and at the sametime transitioning to VB.NET as we have other software products we are moving to .NET. In time perhaps I might be helpful in some regard to core enhancement of modules... Who knows.

But this is another issue that the inner core (the molten core LOL if you will) might want to take a look at. Its one thing when core modules work albeit perhaps not as efficiently as the core framework and require update over time to bat as good a game as the core framework does. It is another to have modules that are considered part of the outer core that simply dont work at all and in this case have not been touched in a year.

This "inner core / outer core" stuff is a tough/mixed bag I know. Believe me I know having been in situations at game dev houses where all of a sudden the next day one gets informed that these coder's have departed and these ones are now in, project leads change... Games Dev. has many (many) bosses all in varying genre's all coming together into one final product.

In the open source arena of DNN I can only imagine. Project leads are familiar with the core and the associated module that is the charge. It can be hard to motivate volunteer work and troublesome to say, "Well you dont have the time (whatall) to devote so we need replace you". Yet, that party may have worked dilligently for a long time, why... there might not even be such a module if it were not for them and knowbody likes to be the moved or mover as again, this isnt a commercial framework.

However... the framework is used by commercial interests as well as countless privateers, some 500,000? of them. In "AAA" games the "whip" exists, basically a Sr. Production Manager who (at least in my experience) appears to be the friend of knowbody except the users/corporate/shareholders. He/she has no pal's on the given project. The sole charge is to make sure everyone is doing. When they are not they are informed either do so or exit. Its harsh. But, in the same regard its understandable as the stakes are high. When you have a "World Of Warcraft Burning Crusade" that in its first 24 hours of release has 2.5 million units sold at $40 a crack.

With DNN the stakes are not as high, or are they? Might they be at some point in time?

The webmaster that grabs DNN because the noted core modules appear to all be their for the task at hand or at least a good portion thereof gets just as frustrated when "This module doesnt work" as a webmaster does when buying a module at SnowCovered to find its not useable.

Just some more food for thought...

Re: DotNetNuke Core Release Process

This is always a difficult process, but in my case I have delayed implementing two new site setups waiting for the 4.5 release. Perhaps if I'd known it was going to be a while before release I'd have installed 4.4x, but the advantages and changes made 4.5 desirable and avoiding any upgrade issues was worth the original wait.

On a whole, I'd rather have a secure and stable relase than a premature one anyway. I guess.

Jeff

Re: DotNetNuke Core Release Process

I certainly appreciate the information on when to anticipate a release. It would be nice if we could get a weekly update since RC3 appears to be so close. Obviously some are going to develop expectations around any date you give so I would be happy with knowing if it is still waiting on the green light or if it has been kicked back for more work (days vs weeks).