Hi! Is it adviseable to use beta modules, developer and alpha version on a live site? I have professionals set up a web site for me and they use modules that are beta, dev. and alpha. FK
In general, what Michel wrote is very accurate, although, IMO, using a RC is definitely a risk that should be avoided whenever possible.
However, some modules have reasonably stable dev releases, or are used in such a limited way that the dev release doesn't pose an issue.
Also, alpha and beta are used inconsistently within the community, and on different modules can mean different things.
So:
If you have hired developers, ask them how they know that the dev/alpha/beta/rc releases are stable --
If you are working on your own, set up test user roles, and run through the actions your users will be doing --
But, whenever possible, avoid using alpha/beta/dev/rc releases.
Cheers,
Bill
michel wrote:
janni frento ha scritto:
Hi!
Is it adviseable to use beta modules, developer and alpha version on a live site?
RC: say "yes" BETA: "at your risk" DEV: "at your your your risk" ALPHA: "is a joke?"
M.
Quoting Bill Fitzgerald bill@funnymonkey.com:
But, whenever possible, avoid using alpha/beta/dev/rc releases.
If everyone followed this advice then these releases would never get tested. Probably most don't anyway but these are released by developers for feedback from the user community. Sure, don't use it in production but please test these and give feedback. That is how we help each other.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Thu, Sep 18, 2008 at 12:25 PM, Earnie Boyd earnie@users.sourceforge.netwrote:
Quoting Bill Fitzgerald bill@funnymonkey.com:
But, whenever possible, avoid using alpha/beta/dev/rc releases.
If everyone followed this advice then these releases would never get tested.
Not remotely true. There are any number of ways to test from development servers. Testing from production is a contradiction in terms. In most cases, it would not be considered professional.
But, as several people have noted, stability varies and labeling is inconsistent. Some features will not directly affect site visitors (as opposed to administrators), or will seldom be encountered, so some judgement on the part of the developer as to when to break the "if it isn't a production version of a module, it probably shouldn't be on a production website" rule, is appropriate.
And having said that, I would still fall back on the knowledge that in the web world, updating is continuous. In most cases, you are far better going live with some features that really work, and adding new features as they are ready, then going live with stuff that is in alpha(!!!!) or beta, or even RC. If there is any complexity to the site, even with supposedly stable modules, you will probably discover things to be fixed post-launch. By keeping variables to a minimum, the likelihood of discovering something that will give people a negative impression of your professionalism or website can be lowered considerably.
My two cents, ari
One problem with this description is the way things are generated. A release that ends in -dev, is automatically generated by the system every time a change is committed. Alpha releases must be based on tags, which means they are a single snapshot of the code, that will never change.
So say a developer makes an Alpha release, states that some of the features aren't complete, but offers it to try anyway. Then say the developer makes a few changes to try to make those new features work correctly, but in the end, introduces a big that corrupts data. This is committed and rolled into a dev release. By your list below, you would choose a -dev release over a working alpha release.
One of the best ways to evaluate a module that has only a -dev release, is by the age of that release. If it's 6-8 months or a year old, and there are no bug reports in the issue queue, it could be more stable than another module's 2.4 release.
Remember here is no guarantee of quality behind anything in contrib.
All any of these labels mean, is that someone took the time to label what *they thought* it should be called and -dev is just the lack of taking time to label anything.
-Mike
On Sep 18, 2008, at 5:38 AM, michel wrote:
janni frento ha scritto:
Hi!
Is it adviseable to use beta modules, developer and alpha version on a live site?
RC: say "yes" BETA: "at your risk" DEV: "at your your your risk" ALPHA: "is a joke?"
M.
[ Drupal support list | http://lists.drupal.org/ ]
__________________ Michael Prasuhn mike@mikeyp.net http://mikeyp.net
On Thu, Sep 18, 2008 at 8:47 AM, janni frento freeknowledge4all@yahoo.com wrote:
Hi!
Is it adviseable to use beta modules, developer and alpha version on a live site? I have professionals set up a web site for me and they use modules that are beta, dev. and alpha.
Generally you should use releases officially tagged as stable by the maintainer, especially if you don't know much about the development work going on for that module and the skills and habits of the maintainer.
But in reality there are many cases of unstable modules officially tagged as stable, and modules where a dev release is the most stable one. A good site developer would have done the research and should know better, so judge by the results.
FK
-- [ Drupal support list | http://lists.drupal.org/ ]
What an interesting discussion. I think the core answer to your real question is: No - it's not a reason to worry, to fault the developers or "accuse" them of doing something wrong. They probably know what they are doing. I don't think your developers would be offended if you "humbly" ask them about it (in a non-accusing way).
The bottom line is that we all work within budgetary and other constraints. Sometimes there is a dev module that does what we want and we are faced with using it or coding our own solution. Sometimes a bug is fixed and committed to dev and it's vital to get that implemented on the site ASAP (I have faced both these situations recently). It all depends on what you need. I released www.cai.org on views and CCK alpha (D6) versions because that's all there was! That was a risky move because thousands of man-hours went into it and potentially could have been lost if something had gone majorly wrong, e.g. with the DB, but it was a calculated risk based on the desire for the D6 i18n features which are a critical component of the site.
Once you get to know drupal you also start to monitor the project pages and issue queues and you get the feeling for which developers produce quality code, deal with issues, etc and you can be more confident with using their stuff, even in pre-release versions.
Fletch
-
Ari Davidow -
Bill Fitzgerald -
Cog Rusty -
Earnie Boyd -
janni frento -
John Fletcher -
Michael Prasuhn -
michel