Hi there! As of the last security release Drupal 4.5 is de facto unsupported. Contributed modules and themes are already no longer repackaged (don't know who changed that and when). I plan to remove the existing tarballs from files/projects so that they are no longer for download. Please voice your objections soon (and you better have very good reasons ;). Cheers, Gerhard
Noooooooooooooo! Why do you need to remove this stuff? There are those who like I have not upgraded yet to 4.6 and are not necessarily in a hurry to jump to 4.7. If for any reason, you should leave things as they are for people who, like me, are jinxed enough to maybe have to do a clean install of 4.5 before going on to the upgrade. I am just paralyzed about upgrading. I have yet to see any good step- by-step on how to do this. So please, don't move anything that people like me may have to use during the countless hours it will take to go up a decimal point. / liza sabater, publisher culturekitchen network On 27.May.2006, at 09:28, Gerhard Killesreiter wrote:
Hi there!
As of the last security release Drupal 4.5 is de facto unsupported. Contributed modules and themes are already no longer repackaged (don't know who changed that and when). I plan to remove the existing tarballs from files/projects so that they are no longer for download. Please voice your objections soon (and you better have very good reasons ;).
Cheers, Gerhard
Why do you need to remove this stuff? There are those who like I have
Leaving it up is, to some, an admission of *support*. We no longer support 4.5 - we won't answer questions about it, help people with it, or blah blah blah. The strongest way we can say this is to remove the downloads in their entirety. You are more than welcome, however, to mirror the download on your own site or hard drive. Just realize that any request for help will fall on deaf ears. -- Morbus Iff ( omnia mutantur, nihil interit ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 5/27/06, Morbus Iff <morbus@disobey.com> wrote:
Why do you need to remove this stuff? There are those who like I have
Leaving it up is, to some, an admission of *support*.
Lisa Also, remember that 4.5 is not patched for the latest exploits, so it is very dangerous to continue to run with that, regardless if it is supported or not ...
Ber , Morbus and all, Would you consider stepping back a moment and thinking as a non- developer? This is the kind of decision that ought to fall on the shoulders of a user-relations team and not developers. I worked at Colgate-Palmolive as the tech and communications writer for their Consumer Affairs department. Colgate-Palmolive is the largest manufacturer of toothpaste in the world, among many other products. They produce everything from dentistry pharmaceuticals to dog food. For four years I wrote the manual on how to handle all sorts of inquiries, complaints and suggestions coming from consumers. My job, was to write human-readable instructions and communications guides for our Consummer Affairs representatives. I was dead against scripts because they show a lack of training and understanding of the products and consumers; and at that time my bosses agreed. Knowledge of all products, past and present, was a part of the training for our reps. I was instrumental in making that happen in the least of techie ways given that this was BEFORE the internet was used by major companies for doing business (1994). I mean, the system I was using was written in a pre-WYSIWYG DOS system. So you can imagine how "cutting edge" and scary for non-techie people that must have been. My job was twofold : I had to help transition consumer-to- company communications from an analog system of communications to this new digital system while also transitioning and streamlining the internal communications all departments affected by consumers (Legal, Marketing, Sales, R&D). One of the biggest percentages of communications was on discontinued products. People would always call or write about products the company had stopped manufacturing for years. Loyal consumers sensing the disappearance of the product would stock up on it. CP spent a lot of time and effort on these particular people. Why? Because if consumers were bound to look for that product high and low it meant they were loyal consumers. The challenge for the company was to transition those consumers to newer products and keep them as word-of- mouth evangelizers. One of the most frustrating aspects of working with Drupal is the lack of forethought on word-of-mouth evangelizing and user loyalty that goes in the development, implementation and the dissemination of the product --and yes, I am calling Drupal a product because that is what it is. Given that you have an open source product it is a mystery to me why you have decided to disappear from your site the history of the product's development. This is a huge loss for future developers who come to the site looking to learn more about the product. If it were up to me, I'd curate a whole section on the development of Drupal. I'd keep each release for historical documentation and, if possible, annotate it with some commentary from not just from developer but particularly from loyal users of Drupal. A product's success does not lie just on it's design or development. A product's success lies on it's word-of-mouth reputation among users. Word-of-mouth is what makes or breaks products and it's why most of the shittiest products succeed. Toys like "Pet Rock" to celebrities like "Paris Hilton" make it all by the grace of their word-of-mouth god. It's not fair but it's what happens in the real world. Back to Ber and Morbuss and most of the developers of Drupal : I just think that as developers, you're way of thinking works best with code. I honestly do not know what it is about this group of developers but you definitely think and work differently than developers in the Movabletype, TextPattern and WordPress development groups. For me, as someone who has been 'looking from the outside in', in all these groups, it's really interesting to see how differently coders work from one product to another ---and it proves software development is a very personal and subjective process; even when done by a group of people. You have a good product and a growing base of non-developers eager to use it. Open archival access to your past success needs to be an important part of how you engage the people who use Drupal. It should be integral to your documentation, which gets better with each passing day. You still need people who are part of core who deal solely with community/user/consumer issues and think about these things. You need more than one person so that developers don't get the opportunity to gang against him/her (as in the Dilbert effect). Which is why, these people need to be regarded as part of the core group of developers. Yes, I do have to agree with the common belief that it's rare to find developers who understand the nuances of community/consumer affairs. They are out there, and you do have some right here within your ranks. But as a development groups go, you have to decide that dealing with the community is just as important as dealing with the code. And more importantly, you need decide on a process on how to go about that, even if it means developers won't be part of that decision making. Which is why I insist : Give away those decisions to people who can do that person-to-person heavy lifting. It will make Drupal.org an infinitely better experience. Best, l i z a sabater www.lizasabater.com AIM - cultkitdiva SKYPE - lizasabater TEL - 646.552.7365 On 27.May.2006, at 11:36, Khalid B wrote:
On 5/27/06, Morbus Iff <morbus@disobey.com> wrote:
Why do you need to remove this stuff? There are those who like I have
Leaving it up is, to some, an admission of *support*.
Lisa
Also, remember that 4.5 is not patched for the latest exploits, so it is very dangerous to continue to run with that, regardless if it is supported or not ...
On 5/27/06, blogdiva@culturekitchen.com <blogdiva@culturekitchen.com> wrote:
Which is why I insist : Give away those decisions to people who can do that person-to-person heavy lifting. It will make Drupal.org an infinitely better experience.
Congratulations liza, you just nominated yourself to head the Drupal person-to-person evangelism team! You are clearly an experienced person in this regard and not afraid to share your opinion - important qualities in that role. FWIW, I will throw my weight behind your opinions to help them avoid being ignored, though I may not agree with your exact methods to achieve those opinions. e.g. I agree that the history needs to be available and documented, but it is available in CVS and that is a reasonable method for anyone who wants to maintain a currently unsupported release. You can signup for the marketing group here: http://groups.drupal.org/drupal-marketing That is probably the best home for a person-to-person evangelism team. I created a base "History of 4.5" page in the handbook because I agree that idea is kind of fun. You can view it and provide comments to help it grow http://drupal.org/node/65867 Welcome aboard! Regards, Greg
Thanks Greg, I hope you are not being sarcastic :) But, since you mention it ... Here's an example of what I was talking about :
On 27.May.2006, at 02:39 PM, Gerhard Killesreiter wrote: Interested parties wil observe that there aren't any earlier releases than 4.5 listed on drupal.org. Our policy was always to support the latest two releases. If we do support, then we offer tarballs, if we don't we don't.
Unless something better comes up, I will remove the files tomorrow.
Why would anybody consider TECH SUPPORT equal to letting consumers of a product have access to older versions of the product? It is not and this is the point I am trying to make. Drupal developers can still choose to not support older versions of the product. What you can do is move them from an active area to an archival one. Let users have access to old files and pages dealing with the versions; regardless of whether you as a developer think it is a good idea or not for people to use those older versions. It's like I tell artists --it is not up to you to tell people how to interpret your artwork. That's only up to the art seeker/lover/ explorer/user/critic. Once you do the work, let the work be. I mean, Drupal is not MicroSoft. Why would Drupal care to force an upgrade if there is no economic incentive for you anyway? What exactly is Drupal.org getting out of it? And this is an honest question, not a rhetorical one. Now, mind you, I am coming back to my original comment : I was to take this weekend to upgrade. For good or bad, I am spending it replying to these emails. So, yeah, I am upgrading anyhow; but this is not about me. My comments have more to do with the elan or spirit that moves members of the development team like Gerhard to make decisions like the one quoted above. It does not help in building community and it certainly is bad for Drupal.org's reputation. / liza On 27.May.2006, at 02:12 PM, Greg Knaddison - GVS wrote:
On 5/27/06, blogdiva@culturekitchen.com <blogdiva@culturekitchen.com> wrote:
Which is why I insist : Give away those decisions to people who can do that person-to-person heavy lifting. It will make Drupal.org an infinitely better experience.
Congratulations liza, you just nominated yourself to head the Drupal person-to-person evangelism team! You are clearly an experienced person in this regard and not afraid to share your opinion - important qualities in that role. FWIW, I will throw my weight behind your opinions to help them avoid being ignored, though I may not agree with your exact methods to achieve those opinions. e.g. I agree that the history needs to be available and documented, but it is available in CVS and that is a reasonable method for anyone who wants to maintain a currently unsupported release.
You can signup for the marketing group here: http://groups.drupal.org/drupal-marketing That is probably the best home for a person-to-person evangelism team.
I created a base "History of 4.5" page in the handbook because I agree that idea is kind of fun. You can view it and provide comments to help it grow http://drupal.org/node/65867
Welcome aboard!
Regards, Greg
Why would anybody consider TECH SUPPORT equal to letting consumers of a product have access to older versions of the product? It is not and this is the point I am trying to make.
You surely skipped Steven Peck's long writing on the subject. 4.5 is somewhat insecure, thus providing access to it is not perceived as a good idea. You can check it out from CVS, and yes, you need to sweat a little if you do not yet know that. But only a little, TortoiseCVS is _really_ easy, have you ever tried it?
Karoly, This has nothing to do with the software but the way drupal developers let be Drupal and Drupal.org. And please, notice how I am parsing these different Drupals. Yes, I understand there are security issues with the software; but there are people running Drupal 4.5 anyway. Why do you want to pull the rug from under them? What do you, as a developer, get from pulling the rug from under people still running 4.5? What does Drupal.org get from throwing out a whole history of comments and tips for earlier versions? Comments like
you need to sweat a little if you do not yet know that.
is killing the reputation of Drupal. This is arrogance. Period. Yes, I know where to find what I am looking for but that's ME. I am not talking about effing me. I am talking here about a whole different way to think about the product, the users, tech support, etc. Honestly ... up to last May I was evangelizing for CivicSpace --Zack knows this. But this kind of attitude from people like you has actually stopped me from recommending Drupal to bloggers in need to upgrade to community management software. It's a pitty because there are good people working with this software (CivicActions, Development Seed, PingV and the now retired Lynn Siprelle are some who come to mind) but the market that I see opening for use of this product ---bloggers in need of community building software-- do not have the budgets of companies or political campaigns ... yet. Back in 2002, MovableType had a boom of transitional users who left Blogger, wanted something nicer than Greymatter, lost out of b2 (which became WordPress and b2evolution) or were tired of Dreamweaving their blogs. There were developers who basically lived off the bounties people put together for their modules. MovableType was what all FOSS should be. Which is why people felt totally betrayed when the company reclaimed their proprietary rights and basically took away the potlatch economy from them. But that's what companies built on proprietary software are meant to do. Drupal is primed for re-capturing that growth; especially as the 2008 elections inch closer. Blogs are passé because they can't scale commenters into communities. And as MySpace and Facebook grow, more bloggers will want to have the ability to replicate that kind of social networking in their own spaces while networking with other sites into affinity networks. It's happening among early adopters. Give it 18 months for the masses to follow. Community management systems will be de-riguer. Can drupal developers get out of the way of potential users? Can you start by letting the Drupal community manage itself? Because, again, do what you have to do in terms of development. Y'all can't support 4.5 with any updates? Cool, no problem. Does it mean the community has to unsupport 4.5 users? No, it doesn't. So archive the information and make it easily accessible for people in the community to pick up that slack. Deal with the code, which is what you do best. Let others deal with users. / liza On 27.May.2006, at 11:12 PM, Karoly Negyesi wrote:
Why would anybody consider TECH SUPPORT equal to letting consumers of a product have access to older versions of the product? It is not and this is the point I am trying to make.
You surely skipped Steven Peck's long writing on the subject.
4.5 is somewhat insecure, thus providing access to it is not perceived as a good idea. You can check it out from CVS, and yes, you need to sweat a little if you do not yet know that. But only a little, TortoiseCVS is _really_ easy, have you ever tried it?
I mostly lurk at this point, but this thread is so chilling that I must add my two cents even though it looks like the group is pretty well decided on wiping away 4.5. While Liza is being a little caustic in telling people that they should stick to being programmers while she's the non-techie expert, she does have a very strong point regarding software availability vs. support. Here's why: NANNY STATE VS. FREE STATE Functionally removing Drupal 4.5 is not just saying "we don't support this, and we highly recommend that you upgrade to 4.7 because 4.5 is a security risk." Removing 4.5 is saying "you WON'T use 4.5 because we don't think that is a good idea." Functionally we're deciding what's best for people, not recommending and giving them the choice. That's like the state telling you how to have sex vs. giving recommendations and ultimately leaving it up to you. If the 4.5 user gets an STD, that's mostly his problem. The compromised site might reflect poorly on Drupal just a tad, just like someone with STDs affects his society. But, is the loss of freedom worth that little net gain for the community? For an open source community, I find it strange that we're effectively dictating what can and cannot be done. CVS ACCESS ALONE FUNCTIONALLY KILLS 4.5 CVS access still is access, but functionally it kills 4.5 for a lot of people because it adds a much higher technical barrier than existed when they initially installed their installation. Putting 4.5 in an archive section effectively warns people against using an old version, but a non-techie who can't easily upgrade still gets access. This less technically inclined or otherwise busy person might not be able to use CVS, however, so we're barring them from 4.5. By removing forum posts, etc., we're cutting 4.5 people off at the knees even more. Far from stopping support, we're actively erasing what already exists. This is as if all major web sites dealing with Win XP are erased when Vista comes out. And yes, other people might have pages about Drupal 4.5 on the web--but as THE place to go for Drupal needs, almost all support for 4.5 is on the Drupal sites that will be erased. DRUPAL IS NOT MICROSOFT WORD MS Word 97 is on a CD and is self-contained, so a user can happily stick with the software for decades assuming he doesn't want the latest features. Drupal doesn't work that way, though, because a good portion of the possible functionality and promise comes from the related modules, themes and code snippets. When I choose 4.5 initially, I know there is certain functionality I can have. And, maybe I don't install it all at once, but I know it exists. By removing 4.5, we're effectively reducing the software to what the user currently has in use--unless of course they decide to download all the modules, all the themes, etc, as well as the docs, the night before it disappears from the Drupal site. Almost nobody will do that, so we're undercutting what the software used to do. 4.5 now is LESS than it was before, which is much different than merely stopping tech support and community development. This isn't a perfect analogy, but removing 4.5 from all but CVS is like stopping Google Maps, not upgrading MS Streets & Trips Planner. Drupal functionally requires community. BUSINESS USE VS. HOBBY USE Hobbyists can get away with cutting edge or even bleeding edge, software that sometimes doesn't work quite right, but businesses don't have that tolerance because the stakes are higher. Businesses started using open source largely when paid support options developed and very stable software versions emerged because they just couldn't gamble with the unstable, absolute latest and greatest. I'm still installing new 4.6 installations for my clients because many modules I need are not yet ported to 4.7. It is scary enough from a business perspective that Drupal is not backwards compatible. Being all but forced to upgrade every other release seriously undercuts Drupal's commercial viability. If Drupal primarily is a hobbyist community that doesn't care about my business needs, why would my business rely on Drupal? Technical elegance only goes so far if the point isn't software for its own sake. Apple Computers changes technical architecture relatively often, but users still can use OS 9 if they're stubborn (and there IS a decent upgrade path usually). By removing 4.5, We're saying businesses that use OS 9 are in deep trouble, more than just "you're on your own, bub." AN ARCHIVE ISN'T HARD TO DO OR COSTLY An archive won't dramatically use server resources if few people use it, and if it does get high use then that's a really strong signal that an archive is especially necessary. What is the really good argument for totally cutting the old community off at the knees? I am pretty busy, and I don't even use 4.5, but I'd be willing to help with an archive section if for some reason creating it takes more work than it seems. The Drupal community really is shooting itself in the foot if it effectively forces people to use the latest and greatest tech, which I think this policy does. Thanks for reading my 4am concerns. I'd much rather be sleeping, but this is too important. -Peter -- Peter Kowalke Port Chester, NY "Plausible fellow, but unsound." -Herbert Bayard Swope, former editor of the New York World
Op zaterdag 27 mei 2006 19:23, schreef blogdiva@culturekitchen.com:
Ber , Morbus and all,
Would you consider stepping back a moment and thinking as a non- developer? This is the kind of decision that ought to fall on the shoulders of a user-relations team and not developers.
I am not sure why my name is in that list. I posted -as a comment- on Dries's site that I am very much in favor of NOT upgrading. I run most of my sites on 4.6 and will continue doing so, untill I see a very good reason to upgrade. Having the latest nitty gritty coolness and ajaxyness is not a reason to upgrade. « Never fix something that aint broken » If I had sites running on 4.5, I would have ported the security patches to these versions. But unfortunately the only sites on < 4.6 are no longer suppported by me, or are discontinued. but for 4.6 we will most probably keep support for a long time. Therefore I beleive we should NOT just remove the stuff, nor "officially not-support". But: This requires maintainers! We need people to manage and support the older versions. I have heard Dries say, over and over, that if there are people willing to do this, he will continue support for any version. Bèr
these versions. But unfortunately the only sites on < 4.6 are no longer suppported by me, or are discontinued. but for 4.6 we will most probably keep support for a long time.
there are people willing to do this, he will continue support for any version.
This letter already indicates that it's very likely that 4.6 support won't go away any time soon (ie. in the fall when 4.8 is out). Ber is likely to lend a hand in supporting, and so do I and very likely a horde of other people who are paid to keep these sites alive. 4.6 was the first to live in the "Drupal boom" era. Regards NK
Op maandag 29 mei 2006 12:35, schreef Karoly Negyesi:
Ber is likely to lend a hand in supporting, and so do I and very likely a horde of other people who are paid to keep these sites alive. 4.6 was the first to live in the "Drupal boom" era.
Correct. And I am rather surprised that no-one does this for 4.5. The amount of people stumbling in on this 4.5 thread shows that there clearly is a "market" for 4.5. So: where are those that want to take that market? Where are those with the itch for maintaining 4.5? Is it just a matter of getting all these people together? Bèr
On 29 May 2006, at 13:59, Bèr Kessels wrote:
Ber is likely to lend a hand in supporting, and so do I and very likely a horde of other people who are paid to keep these sites alive. 4.6 was the first to live in the "Drupal boom" era.
Correct. And I am rather surprised that no-one does this for 4.5. The amount of people stumbling in on this 4.5 thread shows that there clearly is a "market" for 4.5. So: where are those that want to take that market? Where are those with the itch for maintaining 4.5? Is it just a matter of getting all these people together?
What I could do is setup a script that automatically creates a new Drupal 4.6 release every month or so. That is, if there have been changes to the DRUPAL-4-6 branch. We wouldn't announce this release publicly, but people would have an easy way to grab the latest changes. -- Dries Buytaert :: http://www.buytaert.net/
Op maandag 29 mei 2006 14:15, schreef Dries Buytaert:
What I could do is setup a script that automatically creates a new Drupal 4.6 release every month or so. That is, if there have been changes to the DRUPAL-4-6 branch. We wouldn't announce this release publicly, but people would have an easy way to grab the latest changes.
You mean releasing a new drupal 4.6.x+1 release like this? Or do you mean releasing some kind of HEAD on the 4.6 branch this way? Is the current model of 4.x.y+1 release-when-enough-issues-solved, not sufficient, then? Or do I misunderstand you? FYI and everybody interested in these threads, have a look here: http://drupal.org/project/issues?projects=3060&versions=11262,10237,9739,970... these are bugs, for the 4.6 branch. Or for 4,5: http://drupal.org/project/issues?projects=3060&versions=10236,9738,9702,7695... Eventhough most of the 4.6 ones are probably "stale" bugs (bugs that were erronously filed against some stable version and never updated when fixed in some head), a rather big amount of these could be considered for integration in one of these branches. If there were enough reviews. So, if people are so concerned about an old 4.5 version (or any old one), wich is perfectly understandable, there should also be people working on weeding out these bugs, and testing them to get into a new 4.5.x and 4.6.x release. Or at least just maintaining the queue, and closing old and stale issues. (me is to blame here too) IMO the biggest problem is that, for 4.5, there are no people around who *redistribute* any backported (security) patches. For example: I cannot beleive that ecademy is not somehow following our security releases and merging them into their own "fork". There are probably more of such sites which could redistribute any of their fixes. Therefore, we can all jump up and call murder-and-fire (its a Dutch saying, but I am sure you get the point) when 4.5 stuff might be officially not/less maintained. But If there were people whom organised themselves around 4,5 and released (backported) patches for the latest holes, for 4.5, all this would be a non-issue. Bèr
Who are the maintainers for drupal 4.6? What is needed to close or update the bug reports? Best regards, Fernando Silva On 5/29/06, Bèr Kessels <ber@webschuur.com> wrote:
Op maandag 29 mei 2006 14:15, schreef Dries Buytaert:
What I could do is setup a script that automatically creates a new Drupal 4.6 release every month or so. That is, if there have been changes to the DRUPAL-4-6 branch. We wouldn't announce this release publicly, but people would have an easy way to grab the latest changes.
You mean releasing a new drupal 4.6.x+1 release like this? Or do you mean releasing some kind of HEAD on the 4.6 branch this way?
Is the current model of 4.x.y+1 release-when-enough-issues-solved, not sufficient, then? Or do I misunderstand you?
FYI and everybody interested in these threads, have a look here:
http://drupal.org/project/issues?projects=3060&versions=11262,10237,9739,970... these are bugs, for the 4.6 branch.
Dovetailing on Fernando's questions, what can less technical 4.6 users do to extend the useful life of 4.6 after 4.8 has hit the scene? I'm not enough of a programmer to adopt and maintain old modules--I'm more a UI and technical writer type at this point. Better documentation doesn't help preserve abandoned code, though, so I'm wondering what users who are non-programmer can do to preserve 4.6 for the years to come. -Peter On 2006/05/29 11:29 AM, "Fernando Silva" <fsilva.pt@gmail.com> wrote:
Who are the maintainers for drupal 4.6? What is needed to close or update the bug reports?
Best regards, Fernando Silva
That's an awesome question. I'd like to hear from developers and the people in the marketing team. The question is at the core of what I feel Drupal is overlooking at the moment --code freezes. So back to y'all. Oh and totally OT : Hi Peter ... 4 years unschooling my kids and counting. Cheers, liza On 29.May.2006, at 01:03 PM, Peter Kowalke wrote:
Dovetailing on Fernando's questions, what can less technical 4.6 users do to extend the useful life of 4.6 after 4.8 has hit the scene? I'm not enough of a programmer to adopt and maintain old modules--I'm more a UI and technical writer type at this point. Better documentation doesn't help preserve abandoned code, though, so I'm wondering what users who are non- programmer can do to preserve 4.6 for the years to come.
-Peter
On 2006/05/29 11:29 AM, "Fernando Silva" <fsilva.pt@gmail.com> wrote:
Who are the maintainers for drupal 4.6? What is needed to close or update the bug reports?
Best regards, Fernando Silva
*** Liza wrote:
That's an awesome question. I'd like to hear from developers and the people in the marketing team. The question is at the core of what I feel Drupal is overlooking at the moment --code freezes.
*** Peter wrote:
Dovetailing on Fernando's questions, what can less technical 4.6 users do to extend the useful life of 4.6 after 4.8 has hit the scene? I'm not enough of a programmer to adopt and maintain old modules--I'm more a UI and technical writer type at this point. Better documentation doesn't help preserve abandoned code, though, so I'm wondering what users who are non- programmer can do to preserve 4.6 for the years to come.
As I mentioned before, given enough support, I'd be happy to commit patches against the Drupal 4.5 and Drupal 4.6 branch. The more users that are willing to stick with Drupal 4.5 or Drupal 4.6, the more likely it is going to be maintained. You can answer Drupal 4.5 and Drupal 4.6 related support questions in the forums; that certainly helps to maintain the community around Drupal 4.5 and Drupal 4.6. Getting excellent support for Drupal 4.5 and Drupal 4.6 related problems might be a reason not to upgrade. You can spend time in the issue tracker; test patches, help make sure that bug reports are easy to understand, and that bugs can be reproduced easily. (You don't need to be a developer for this; testing != developing.) It lowers the barrier for developers to look at your bug reports. Or, if Drupal 4.5 or Drupal 4.6 is really important for you, you can hire a developer to look at your problem, or to backport security fixes. Getting someone to backport security issues looks essential to me. -- Dries Buytaert :: http://www.buytaert.net/
On 30.May.2006, at 02:49, Dries Buytaert wrote:
Getting excellent support for Drupal 4.5 and Drupal 4.6 related problems might be a reason not to upgrade.
No, not really. In my case it is the amount of time and money expended on making 4.6+ just right. The site is just running smoothly after 4 months of debacles. I just dont have the resources to basically start a fresh batch of massive debugging and server crashes. If I had known 18 months what I know now --and grock knows I asked and researched all these issues-- I would have not moved to CivicSpace/Drupal. If this were a soap opera, the honeymoon is over and i am trying to make this relationship work. So given my mixed bag experience, I am honestly thinking how I can make this situation not only better for myself but for others. Documentation is the first step. Once I'm done with the upgrade, I'll send stuff to the Docu people for review. Anyhow, thanks for the heads up, /liza
On 5/30/06, blogdiva@culturekitchen.com <blogdiva@culturekitchen.com> wrote:
That's an awesome question. I'd like to hear from developers and the people in the marketing team. The question is at the core of what I feel Drupal is overlooking at the moment --code freezes.
Code freezes do happen. Once we have a release, its API does not change (may be a tiny bit occasionally, but not normally). What we do not freeze is APIs between releases. How can we move forward from 4.7 to 6.6 with the API remaining the same? Where would the new stuff go? Are you advocating we keep APIs forever? Read my comment here on where the energy should be focussed (migration tools, transitional releases, and compatibility layers). http://baheyeldin.com/node/617
On Tue, May 30, 2006 8:59 am, Khalid B said:
On 5/30/06, blogdiva@culturekitchen.com <blogdiva@culturekitchen.com> wrote:
That's an awesome question. I'd like to hear from developers and the people in the marketing team. The question is at the core of what I feel Drupal is overlooking at the moment --code freezes.
Code freezes do happen. Once we have a release, its API does not change (may be a tiny bit occasionally, but not normally).
What we do not freeze is APIs between releases. How can we move forward from 4.7 to 6.6 with the API remaining the same? Where would the new stuff go? Are you advocating we keep APIs forever?
Read my comment here on where the energy should be focussed (migration tools, transitional releases, and compatibility layers).
Honestly, I think part of the issue with the "stable API" question is that Drupal uses version numbers differently from many projects. The de facto standard for version numbers for most projects is Major.Minor.Bug / x.y.z. Z increases only fix bugs. Y increases add features, but don't break backward compatibility with 3rd party code. X increases, all bets are off. Witness, for instance, KDE, which has evolved and improved dramatically in the 3.y.z cycle, but code for 3.0.0 still (generally) works in 3.5.1. For the upcoming 4.0, howver, there are no "sacred cows" and everything will need to be updated. For Drupal, Y increases, all bets are off. We technically don't have Y releases, just Z and X, but we use both of the first two numbers for the X releases. That throws a lot of people off. It actually surprised me a great deal, although fortunately it didn't affect my plans significantly. Whatever else we do, we should probably make that clearer right up front. It's not inherently a bad development model, just an unconventional one that needs to be made clearer. --Larry Garfield
Honestly, I think part of the issue with the "stable API" question is that Drupal uses version numbers differently from many projects. The de facto standard for version numbers for most projects is Major.Minor.Bug / x.y.z.
Z increases only fix bugs. Y increases add features, but don't break backward compatibility with 3rd party code. X increases, all bets are off.
Witness, for instance, KDE, which has evolved and improved dramatically in the 3.y.z cycle, but code for 3.0.0 still (generally) works in 3.5.1. For the upcoming 4.0, howver, there are no "sacred cows" and everything will need to be updated.
For Drupal, Y increases, all bets are off. We technically don't have Y releases, just Z and X, but we use both of the first two numbers for the X releases. That throws a lot of people off. It actually surprised me a great deal, although fortunately it didn't affect my plans significantly.
Whatever else we do, we should probably make that clearer right up front. It's not inherently a bad development model, just an unconventional one that needs to be made clearer.
I do support Larry's view on this. 4.x.x has been around too long, and there is no compatibility for between its releases. We need to follow the "If X changes, APIs break", and not Y.
That's the first comment in this thread that's both new and useful. On 5/30/06, Larry Garfield <larry@garfieldtech.com> wrote:
Honestly, I think part of the issue with the "stable API" question is that Drupal uses version numbers differently from many projects. The de facto standard for version numbers for most projects is Major.Minor.Bug / x.y.z.
Z increases only fix bugs. Y increases add features, but don't break backward compatibility with 3rd party code. X increases, all bets are off.
Witness, for instance, KDE, which has evolved and improved dramatically in the 3.y.z cycle, but code for 3.0.0 still (generally) works in 3.5.1. For the upcoming 4.0, howver, there are no "sacred cows" and everything will need to be updated.
For Drupal, Y increases, all bets are off. We technically don't have Y releases, just Z and X, but we use both of the first two numbers for the X releases. That throws a lot of people off. It actually surprised me a great deal, although fortunately it didn't affect my plans significantly.
Whatever else we do, we should probably make that clearer right up front. It's not inherently a bad development model, just an unconventional one that needs to be made clearer.
--Larry Garfield
I will definitely check out the post. Thanks. On 30.May.2006, at 09:59, Khalid B wrote:
On 5/30/06, blogdiva@culturekitchen.com <blogdiva@culturekitchen.com> wrote:
That's an awesome question. I'd like to hear from developers and the people in the marketing team. The question is at the core of what I feel Drupal is overlooking at the moment --code freezes.
Code freezes do happen. Once we have a release, its API does not change (may be a tiny bit occasionally, but not normally).
What we do not freeze is APIs between releases. How can we move forward from 4.7 to 6.6 with the API remaining the same? Where would the new stuff go? Are you advocating we keep APIs forever?
Read my comment here on where the energy should be focussed (migration tools, transitional releases, and compatibility layers).
Hi Ber, It's been fascinating to follow this whole thread. I am not so much on the market for 4.5 as I am on the market on making Drupal easier and more cost effective to use and maintain. Laura sent just popped this page after this discussion http://drupal.org/node/65922 And it sent shivers down my spine with its conclusion :
6. Therefore, people adopting Drupal for their web or CMS project should plan for periodic upgrades of their project to the latest major release (every 6-12 months) in order to benefit from the ongoing active support of one of the finest open source development communities.
If you won't code freeze that means I have to do with my sites. The problem is that there is no structure in place at all for people like me or Peter to effectively do so. I don't know what the answer to this issue is, but I know the issue is big enough for me to have pondered this for the past 4 months. I've spent a lot of time smoothing the fuglies out of my sites. You know Drupal sites because they never look quite done. The devil is in the details and a lot of detailing gets brushed aside for functionality. For someone who actually hates spending time on the little things, I actually wished it were the little things, the details, that moved Drupal's development. Which is why upgrading is costly. When you've tweaked things in 20, 30, 50 heres and theres, writing over them for the next decimal upgrade becomes prohibitive. It's time and money gone completely out of the window. From a consultant's perspective this is great because it ensures you're gonna get paid for a while. Form the point of view of a small publisher, the problem is terrible. The promise of using Drupal, after all the research I did almost 1.5 years ago, was that its CivicSpace distro would make it possible for people like me to run community sites for not much more than the cost of running a blog. I knew it was going to be a bit more than that but not this much. Again, I don't have an answer to this issue. i just want to put out there. Liza Sabater, Publisher culturekitchen network www.culturekitchen.com TEL - 646.552.7365 AIM - cultkitdiva SKYPE - lizasabater NOTICE: Due to Presidential Executive Orders, the National Security Agency may have read this email without warning, warrant, or notice. They may do this without any judicial or legislative oversight. You have no recourse nor protection save to call for the impeachment of President George W. Bush and Vice-President Richard Cheney, for high crimes and misdemeanors. On 29.May.2006, at 07:59, Bèr Kessels wrote:
Op maandag 29 mei 2006 12:35, schreef Karoly Negyesi:
Ber is likely to lend a hand in supporting, and so do I and very likely a horde of other people who are paid to keep these sites alive. 4.6 was the first to live in the "Drupal boom" era.
Correct. And I am rather surprised that no-one does this for 4.5. The amount of people stumbling in on this 4.5 thread shows that there clearly is a "market" for 4.5. So: where are those that want to take that market? Where are those with the itch for maintaining 4.5? Is it just a matter of getting all these people together?
Bèr
Perhaps a "4.5 Developers" group at groups.drupal.org will help people find each other. blogdiva@culturekitchen.com wrote:
Hi Ber,
It's been fascinating to follow this whole thread. I am not so much on the market for 4.5 as I am on the market on making Drupal easier and more cost effective to use and maintain.
Laura sent just popped this page after this discussion
And it sent shivers down my spine with its conclusion :
6. Therefore, people adopting Drupal for their web or CMS project should plan for periodic upgrades of their project to the latest major release (every 6-12 months) in order to benefit from the ongoing active support of one of the finest open source development communities.
2006/5/30, sime <info@urbits.com>:
Perhaps a "4.5 Developers" group at groups.drupal.org will help people find each other.
+2 but it shouldn't focus on developers in its name.. it must be a place where 4.5 users may help each others and share tricks. -- "4.5 still.." ?
Which is why upgrading is costly. When you've tweaked things in 20, 30, 50 heres and theres, writing over them for the next decimal upgrade becomes prohibitive. It's time and money gone completely out of the window.
From a consultant's perspective this is great because it ensures you're gonna get paid for a while. Form the point of view of a small publisher, the problem is terrible.
Liza et al: I really can¹t bear to let this thread go on any longer. I know what Laura is getting at, and she is absolutely spot on in that thread. But, I disagree with you about the severity of the problem of unsupported older versions. Fact of the matter is, 6-12 month upgrade timeframes are actually conservative in this era, and rapid upgrade cycles are absolutely indemic in web development, a.k.a., they are actually a good thing. The reason the web is what it is, rapidly evolving and changing is namely because of the rapid pace at which things are moving. The idea of slowing down to support those who don¹t want to upgrade or who can¹t handle the time/money (they are the same) investment is (so!) not a good one. I personally think that Drupal is moving too slowly! I worry about it falling behind, and other worthy competitors coming out that really could give Drupal a run for it¹s money. There certainly are, to those of us who follow Open Source and OS CMS particularly, a number of possible competitors. It¹s really important that we keep adding new features, and Drupal is headed towards some major architectural changes, which I doubt will be backwards compatible, and which are necessary in the near/mid term to keep the platform viable as a development platform. I¹m really looking forward to seeing this community in action!! I was involved in the eZ Publish (ez.no) community when they went from the 2.x series to the 3.x series, and I listened to a lot of posts about how it was going to damage businesses, and how could they stop support? EZ was kind enough NOT to stop support, and in fact kept the 2.x version up for a long time. We still to this day have customers running 2.x platforms on our servers, often after significant investment in customization, and there entire purpose is to try to get their money¹s worth out of the platform before it catastrophically fails. It¹s become impossible for US to support them, and I honestly feel bad for them, but the platforms are making money and/or fulfilling their requirements for their owners, so I understand where they are coming from. But I blame the 2.x updates for this, because it made a lot of site owners complacent. Instead of upgrading, they settled on a release, and now they¹re absolutely, totally, utterly and completely screwed because the cost of moving to the better development 3.x platform is sky-high they would have been better off getting hit by the incremental costs. I like to call this a ³fake fork². Often because there is a remedial but incomplete effort to ³fork² the project in response to the progression, usually by a couple of specialists in that particular version who are very invested in the code base. It¹s basically where the OS project has moved on, and nobody but a few consultants will benefit from the ongoing work. From a businesses perspective, the results of participation in a ³fake fork² can be absolutely devastating. No support from the community, lock in from a few consultants, and no clear upgrade path are just a few of the reasons that settling on a particular version that¹s too far off the source control¹s head is a bad idea. I¹ve got customers who have 250k US in software investment in platforms that are dead because some consultant sold them a solution they couldn¹t feasibly maintain. Now, because they implemented on a particular version of a product as one project, rather than incrementally investing in continuous basis, they¹re 250k from having anything maintainable and have nobody to turn to certainly the consultant is long gone once they couldn¹t keep the customer happy. And the platform is making their daily bread, so they¹re locked in to using it. There are a number of ways that OS Projects and Organizations can cope with change. But they are strategic compromises in investment vs return. If you look at this not from a developer¹s perspective, but from an investor¹s for a moment, you¹ll see that often these users see Open Source systems as a strategy instead of an approach. From an investor¹s point-of-view, the decision to use an Open Source platform for your development is the decision NOT to use a commercial alternative. And part of this compromise is inherently (on the little checklist of OS VS Commercial that business people like to make) to embrace this rapid development cycle of OS, be it Linux, eZ or Drupal. It¹s actually in vogue to consider the rapid speed of revision a technical and commercial advantage! If you need a 5 year support horizon, which many organizations do, then you shouldn¹t be using an Open Source CMS. You should be using Redhat, or IBM, or one of the big CMS vendors. Commercial organizations are paid to keep their support organization going for versions of their software that are put into production. Open Source projects cannot afford to dedicate the resources to doing so, nor is it really in the best interest (or interesting) for the user community to do so. If you need long support horizons, use a commercial product. So, the idea of clinging on to a release that is already past is absolutely terrible. It works backwards from what you are claiming to want to achieve i.e. a sustainable user community and happy consumers of the product, and lower overall costs (it¹s false economy to think so). Absolutely the only person it benefits is the consultant who¹s doing the work. And nobody ultimately benefits. The people who stay on the version end up on a ³fake fork², the user community may get materially fragmented, the users end up with a ³tough luck pal² response from the community for support, and good developers end up sidetracked on projects that do nothing to drive the platform forward and in fact generally damage everyone involved with them. Sometimes tremendously... I say, archive the old versions, let people make their own mistakes if they want to run them, but Drupal needs to drive forward with laser focus to delivery on the promise it has given it¹s Open Source community that it will be one of, if not the, absolute best platforms out there. And one of the compromises people make by using the platform is keeping up with the rapid pace of innovation that is delivering that promise. If anything, Drupal needs to move forward towards continuous integration and test-driven development, so changes can be more rapidly integrated into consuming sites. If anything, we need to get more customers on a daily or weekly upgrade, and build systems to help drive upgrades that make it easier to do so. Locking stuff down, or supporting old platforms, will kill Drupal. This beast breaths with every new release. Dries has already laid down the word on this, and I agree with his approach. Let¹s make the archives available (they are), but not spend any time on it. Customers who are on the platform should know the risks of using an Open Source platform. If this is a serious issue, I would post to the Drupal.org site some content that will help people understand what they are taking on with an Open Source platform, i.e. Rapid integration, many upgrades, and relatively continuous integration projects as new tools (like the forms api) are released. I also back Laura¹s doc (nice approach!), who said it mighty well and whom I work with and respect. Please, let¹s move on. Jonathan
On 5/29/06 11:02 PM, "Jonathan Lambert" <j@firebright.com> wrote:
Which is why upgrading is costly. When you've tweaked things in 20, 30, 50 heres and theres, writing over them for the next decimal upgrade becomes prohibitive. It's time and money gone completely out of the window.
From a consultant's perspective this is great because it ensures you're gonna get paid for a while. Form the point of view of a small publisher, the problem is terrible.
Liza et al:
I really can¹t bear to let this thread go on any longer. I know what Laura is getting at, and she is absolutely spot on in that thread. But, I disagree with you about the severity of the problem of unsupported older versions.
Sorry to reply to my own post, but a couple more points: * I strongly do not want to see fragmentation in the user community around version releases. I like you guys. I want you to keep on for the duration. ;-) * I really strongly encourage anyone on the 4.5 code base or similar to upgrade as soon as possible. I have seen what happens when you don¹t. I¹ve listened to a lot of arguments from people using an older platform (it¹s almost always those who are on the platform that make the argument), but I can tell you it¹s in your best interest, and your customer¹s best interest, to keep up with current releases, and fix/rebuild anything build on old releases as opposed to trying to protect the investment it¹s definitely a false safety. My comments are said from the most good natured perspective I can muster I don¹t want to see user community fragmentation, and sure would like to never see anything screwed customer on an Open Source platform. It really burns me as a business owner when a fellow business owner is in a bad situation, and I¹ve seen too many cases where someone stopped at a release (for whatever reason) and almost universally the customer ended up screwed! Know that I provide these comments with only the best interest of the end-users in mind. I¹m not intending to flame anyone in particular. That point is the reason for my post back. My 2c. Jonathan
2006/5/30, Jonathan Lambert <j@firebright.com>:
[...]
There are a number of ways that OS Projects and Organizations can cope with change. But they are strategic compromises in investment vs return. If you look at this not from a developer's perspective, but from an investor's for a moment, you'll see that often these users see Open Source systems as a strategy instead of an approach. From an investor's point-of-view, the decision to use an Open Source platform for your development is the decision NOT to use a commercial alternative. And part of this compromise is inherently (on the little checklist of OS VS Commercial that business people like to make) to embrace this rapid development cycle of OS, be it Linux, eZ or Drupal. It's actually in vogue to consider the rapid speed of revision a technical and commercial advantage! If you need a 5 year support horizon, which many organizations do, then you shouldn't be using an Open Source CMS. You should be using Redhat, or IBM, or one of the big CMS vendors.
Commercial organizations are paid to keep their support organization going for versions of their software that are put into production. Open Source projects cannot afford to dedicate the resources to doing so, nor is it really in the best interest (or interesting) for the user community to do so. If you need long support horizons, use a commercial product.
So, the idea of clinging on to a release that is already past is absolutely terrible. It works backwards from what you are claiming to want to achieve – i.e. a sustainable user community and happy consumers of the product, and lower overall costs (it's false economy to think so). Absolutely the only person it benefits is the consultant who's doing the work. And nobody ultimately benefits. The people who stay on the version end up on a "fake fork", the user community may get materially fragmented, the users end up with a "tough luck pal" response from the community for support, and good developers end up sidetracked on projects that do nothing to drive the platform forward and in fact generally damage everyone involved with them. Sometimes tremendously... [..] Dries has already laid down the word on this, and I agree with his approach. Let's make the archives available (they are), but not spend any time on it. Customers who are on the platform should know the risks of using an Open Source platform. And if support is really needed, it should come from the community of users/addicts.. If this is a serious issue, I would post to the Drupal.org site some content that will help people understand what they are taking on with an Open Source platform, i.e. Rapid integration, many upgrades, and relatively continuous integration projects as new tools (like the forms api) are released. I also back Laura's doc (nice approach!), who said it mighty well and whom I work with and respect.
Please, let's move on.
Thanks Jonathan, it's a clever summary. It's time now this thread stops. Regards
At 11:02 PM -0700 29/5/06, Jonathan Lambert wrote:
And nobody ultimately benefits. The people who stay on the version end up on a "fake fork", the user community may get materially fragmented, the users end up with a "tough luck pal" response from the community for support
This is where Drupal has real problems. Because Drupal's API changes so radically and so often, it pretty much forces established sites with any customizations at all to stick with whatever version they first built their site on. And since people (at least the ones I know) expect their site to last longer than 12 months they will inevitably find themselves using an insecure, unsupported version of Drupal.
If anything, we need to get more customers on a daily or weekly upgrade, and build systems to help drive upgrades that make it easier to do so.
I don't see how this would be possible with anything but a trivially simple site that used nothing but core modules. But any site that uses a contrib module has to wait for that module to be updated. Any site which has custom code that depends on a changed part of the API will break. All you'd be doing by pushing weekly updates is spreading the pain of an upgrade out so that you have a little pain every week rather than one massive ache every 6 months. Either way, using Drupal hurts. ...R.
And since people (at least the ones I know) expect their site to last longer than 12 months they will inevitably find themselves using an insecure, unsupported version of Drupal.
That just happens to be an unrealistic expectation for Drupal (or most OS CMS systems) at this time. Look, you're missing my point. The point is that to use Open Source systems you have to take the good with the bad. Want access to the latest technology? Upgrade. Want the latest security patches? Upgrade. If you want a longer support timeframe, go commercial. OR, get with the program. You're on an Open Source platform. You will have to upgrade. Drupal could do better on backwards compatibility sure. But you wouldn't have the forms api in core on 4.7; you wouldn't have nearly as much cool stuff. To get this cool stuff, you have to? Upgrade! If you need a longer support horizon, use a commercial alternative. Open Source platforms have a cost - it's time investment. You have to invest in upgrades. If you can't do upgrades, you pay with dollars. That's just the economics of Open Source. Hardly worth arguing about really.
If anything, we need to get more customers on a daily or weekly upgrade, and build systems to help drive upgrades that make it easier to do so.
I don't see how this would be possible with anything but a trivially simple site that used nothing but core modules.
You snipped the answer right from my post! "move forward towards continuous integration and test-driven development, so changes can be more rapidly integrated into consuming sites" Change management, and I can tell you since my job every day is to oversee a lot of very high traffic Drupal websites, is the holy grail of Open Source systems and the emerging hosting/SaaS businesses around the model. It's not solved yet. There is no "way", other than the "way of the keyboard" (so called "manual mode" ;-) to handle upgrades. However, continuous integration and test-drive development mean you can keep your site up-to-date until it breaks, then fix whatever broke it. I just think that those folks who want to fragment the 4.5 user group, and build support for old releases simply don't like the answer, not that the answer isn't there. The answer, plain and simple, is that it's the cost of doing business on Open Source platforms.
But any site that uses a contrib module has to wait for that module to be updated. Any site which has custom code that depends on a changed part of the API will break.
False. Any site that uses a contrib module has to wait for that module to be updated, OR pay for someone to update it, OR update it themselves. Look, the core foundation of Open Source is that users participate in ongoing development. If you find yourself waiting on a core developer to update a patch, update it yourself or start nicely harassing the module maintainer (believe me, it's motivating to hear from users!). This is an inherent weakness in Drupal's current model, so in fact Drupal should move to correct the problem, not move to build a process to keep the problem from recurring. Another way of looking at this problem is that core modules should be tied to a revision of the API, so that they do not break until upgrades, so perhaps the API should be versionable! Wouldn't that solve the problem as well? Does anyone remember the pain of moving from glibc was? I remember seeing so many 'GLIBC_2.2' not found errors, I was losing hair! This was the same problem in Linux! The same exact problem. Or moving from php 4.0.x to 4.1.x or 5.0.x? Oh man, does that break a lot of stuff. So does that mean we should create a php version that's supported so that nobody has to upgrade? Not inherently. The fact is that a supported php version that's for older releases makes more sense than an older Drupal version, as it would affect a huge number of Open Source customers and in fact has a massive diseconomy for non-support. But they still don't do it! Why not? My point is that looking at today's problems with today's eyes isn't what this platform is all about, and you can't actually see the forest for the trees when you're invested in a particular revision of a product. You need to step beyond your "project scope", and into "Open Source" scope, and realize that the need to upgrade comes from the very vitality and growth of the platform you are using. Also, the arguments for support of old platforms miss an important economic point. The different in cost in moving from 4.5 to 4.6 OR from 4.5 to 4.7 are an order of magnitude larger. It's a MASSIVE effort, as you have to upgrade twice, and one of those times stabilize a system (and associated modules) without any material benefit to the site. That's a terrible waste of time. It's much cheaper just to stay with current releases, absorb the annoyance that comes with frequent upgrades, and avoid all the pitfalls I have laid out already.
All you'd be doing by pushing weekly updates is spreading the pain of an upgrade out so that you have a little pain every week rather than one massive ache every 6 months.
No, continuous integration would mean you'd have really no pain unless it broke, and then you could roll back until you wanted to fix why it broke. It's a completely different way of looking at software, and is much more oriented towards modern platforms that look less like "webware" and more life software, of which Drupal is fast becoming a material participant.
Either way, using Drupal hurts.
Got something better? Jonathan
Also, the arguments for support of old platforms miss an important economic point. The different in cost in moving from 4.5 to 4.6 OR from 4.5 to 4.7 are an order of magnitude larger. It's a MASSIVE effort, as you have to upgrade twice, and one of those times stabilize a system (and associated modules) without any material benefit to the site. That's a terrible waste of time. It's much cheaper just to stay with current releases, absorb the annoyance that comes with frequent upgrades, and avoid all the pitfalls I have laid out already.
Upgrading from Drupal 4.5.x to 4.7.x is not much of a pain really, in case you use core modules only. In fact I devoted a big chunk of my time around christmas to fix bugs in the 4.5 -> 4.7 upgrade path. The core is ready for you to upgrade from 4.5 to 4.7 directly, there are specific functions to help this migration. Drupal.hu still runs on 4.5 and is going to get an upgrade to 4.7 soon. Thanks to the work put into the upgrade system, the data migration is just a click of a button. Of couse we add new stuff to the site and reorganize existing functionality, and that takes time. Also if you use custom modules, you need to invest your time into it, but core supports the direct upgrade nicely. Gabor
On 30.May.2006, at 02:02, Jonathan Lambert wrote:
But, I disagree with you about the severity of the problem of unsupported older versions.
I just want to make the observation that you are confusing support of Drupal the product with suppport of users. They are not one and the same. As I said before, Drupal developers can choose not to work on old code. The issue is how to make it easy and cost-efficient for users to upgrade and ride the wave of innovation. Cheers, liza
On 30 May 2006, at 08:02, Jonathan Lambert wrote:
I personally think that Drupal is moving too slowly! I worry about it falling behind, and other worthy competitors coming out that really could give Drupal a run for it’s money. There certainly are, to those of us who follow Open Source and OS CMS particularly, a number of possible competitors. It’s really important that we keep adding new features, and Drupal is headed towards some major architectural changes, which I doubt will be backwards compatible, and which are necessary in the near/mid term to keep the platform viable as a development platform. I’m really looking forward to seeing this community in action!!
As Darwin said, it's not the strongest organisms that win, it's the most adaptable. This applies to the Drupal project in general, but also to each individual Drupal installation. It is why we will break backward compatibility if we have to [1], why I keep hammering on the fact we need to make Drupal easier to develop for [2], and ultimately, why we need to make it easier for people to upgrade. I have given this quite a bit of thought lately, and I really think it is _that_ simple. [1] http://buytaert.net/backward-compatibility [2] http://buytaert.net/complexity-is-a-disease -- Dries Buytaert :: http://www.buytaert.net/
If you need a 5 year support horizon, which many organizations do, then you shouldn¹t be using an Open Source CMS. You should be using Redhat, or IBM, or one of the big CMS vendors.
This might be the crux of the thread. Business commonly needs a longer software lifecycle, so we're telling businesses to go elsewhere. Effectively saying no to business use will doom Drupal much faster than anything I can imagine. Some OSS projects are healthy and business friendly. Why can't Drupal be one of theme? The best technical products don't usually win in the end--the winners are the best technical products that ALSO cater to businesses and laymen. How can Drupal thrive and grow like a mySQL or a Linux or a PHP? Technical innovation is part of the answer, but not all of it.
I say, archive the old versions, let people make their own mistakes if they want to run them, but Drupal needs to drive forward with laser focus to delivery on the promise it has given it¹s Open Source community that it will be one of, if not the, absolute best platforms out there. And one of the compromises people make by using the platform is keeping up with the rapid pace of innovation that is delivering that promise.
I thought the point was usability, not just innovation? Drupal is community plumbing that makes an online community run much better. If I'm under the sink every month or two, that's not very good plumbing! I may need new pipes installed for that newfangled beer faucet, but the promise of the beer faucet isn't why I installed the plumbing to begin with. Amen to a clearly labeled and easy to use archive where those too poor, too stupid, too contented or too technically shaky can continue to use their old Drupal installations. Let the community march on, but without burning or hiding what came before. I'd like to see a http://archive.drupal.org/ for anything 4.5 and below. If Drupal is going to press ever onward with technical innovation, which it should, it needs more than just a well-marked archive. From a business mindset it needs: 1) A really easy upgrade path. Maybe an auto-update feature--although I know that gets sticky really fast given homemade modules...there would need to be a lot of thought on how to do it sanely. 2) If not an unchanging API, then an API abstraction layer of some kind. Wouldn't it be great if a 4.5 user could install an API-engine of sorts that would allow him to run 4.5 modules and stuff on a newer install? Definitely there would be a performance hit when the 4.5 mods were used, but someone who absolutely needed an old mod or whatever could do it. Microsoft caters too much to legacy code, and we all know how bad that has been. Apple changed too often, hurting business, but then the tech got better and they wised up--people now can emulate their old software on a Mac if they're willing to take a performance hit. This is where Drupal should go if technically possible--and hey, this is a way that legacy support BECOMES a technical innovation. If an API-engine concept was developed, Drupal probably would have my heart for life. :-) 3) An easy way for less technical people to know the stability of a contributed module. Some modules are constantly being improved, and there is no doubt they will update with each new Drupal release. Other modules are close to dormant, and there's a good chance they are Drupal version specific because they're a niche module and the creator doesn't really support it any longer. As a business person, I need to have at least a sense which modules I can rely upon--I might go with Drupal if mailhandler is updated regularly, but I'll probably pass on Drupal if it really only is a 4.6 module. Worse, I might go with Drupal then curse the community if I think mailhandler is a long-term module and it goes away in 4.7. There are ways to get a sense for this if you're experienced, but I think a lot of new or non-technical users can't see the signals--and no, they also can't adopt the project(s) if they foolishly rely on a 4.6-only mod. We need a warning system that gauges risk. I'd be more than happy to lay out ideas on this if others are interested.
I can tell you it¹s in your best interest, and your customer¹s best interest, to keep up with current releases, and fix/rebuild anything build on old releases as opposed to trying to protect the investment it¹s definitely a false safety.
Any site that uses a contrib module has to wait for that module to be updated, OR pay for someone to update it, OR update it themselves.
Money is a factor for open source adoption, too--a lot of non-profits that can't afford commercial CMSes use open source instead. OSS also is gaining a following in less developed countries because anyone can get the software (not just because anyone can develop it). I see open source as being more than just about technological innovation at this point. It is many things to many people--and a common one is its use as a cheaper alternative. I don't want to damn all these folks who need it but can't afford to hire a consultant or learn the skills to do it themselves. Software is for the technical user, first and foremost--but the breakthrough OSS projects have been those that reach and help a wider market. And, I'd like to think this wider market often helps improve the software in the long run, too. -Peter -- Peter Kowalke Port Chester, NY
Peter Kowalke wrote:
If you need a 5 year support horizon, which many organizations do, then you shouldn¹t be using an Open Source CMS. You should be using Redhat, or IBM, or one of the big CMS vendors.
This might be the crux of the thread. Business commonly needs a longer software lifecycle, so we're telling businesses to go elsewhere. Effectively saying no to business use will doom Drupal much faster than anything I can imagine.
Drupal has been doing fine before anybody was doing business with it.
Some OSS projects are healthy and business friendly. Why can't Drupal be one of theme?
Drupal is very friendly to my business. :) (and no, I am not referring to site upgrades, my clients are usually tech-savvy enough to do that themselves)
The best technical products don't usually win in the end--the winners are the best technical products that ALSO cater to businesses and laymen. How can Drupal thrive and grow like a mySQL or a Linux or a PHP?
IMNSHO it is doing just fine. I am handing out new CVS accounts like I've never done before.
Technical innovation is part of the answer, but not all of it.
It seems to suffice for my clients.
I say, archive the old versions, let people make their own mistakes if they want to run them, but Drupal needs to drive forward with laser focus to delivery on the promise it has given it¹s Open Source community that it will be one of, if not the, absolute best platforms out there. And one of the compromises people make by using the platform is keeping up with the rapid pace of innovation that is delivering that promise.
I thought the point was usability, not just innovation? Drupal is community plumbing that makes an online community run much better. If I'm under the sink every month or two, that's not very good plumbing! I may need new pipes installed for that newfangled beer faucet, but the promise of the beer faucet isn't why I installed the plumbing to begin with.
Nice analogy. :p But it doesn't hold, especially since you are setting such a short timeframe. Drupal.org for example hasn't had any updates from about November till March. We needed to wait for modules to be updated just like anybody else. This wasn't a problem at all and the update in March was a little bit exciting but nothing major, thanks to a lot of people who contributed. And drupal.org is still one of the bigger sites out there with some contributed modules and a custom theme.
Amen to a clearly labeled and easy to use archive where those too poor, too stupid, too contented or too technically shaky can continue to use their old Drupal installations. Let the community march on, but without burning or hiding what came before.
I'd like to see a http://archive.drupal.org/ for anything 4.5 and below.
Given the CVS access I don't really see the point, but I also don't mind.
If Drupal is going to press ever onward with technical innovation, which it should, it needs more than just a well-marked archive. From a business mindset it needs:
1) A really easy upgrade path. Maybe an auto-update feature--although I know that gets sticky really fast given homemade modules...there would need to be a lot of thought on how to do it sanely.
I am looking forward to your contributions to this project... Frankly, I think it isn't worth the effort, but if you volunteer to throw enough time and/ or money at the problem, you can probably find a semi-stable way to do that.
2) If not an unchanging API, then an API abstraction layer of some kind. Wouldn't it be great if a 4.5 user could install an API-engine of sorts that would allow him to run 4.5 modules and stuff on a newer install?
Yeah, I am looking forward to all the complaints about "Why can't Drupal run with 64M of PHP memory anymore?" too. Drupal is and will always be a web application written in an interpreted language. This means you can't do stuff with it that you can with eg an operating system (running several Linuxes on one machine or other heavy-duty stuff) or a desktop application. This just won't fly. And I rather have a fast Drupal with a somewhat rugged upgrade path than a slow Drupal where I can do ultra-smooth upgrades and run old code inside an emulation layer. Hint: The update is done once every six to twelve months, the webserver runs 24 hours a day. And being able to use Drupal on less than fresh hardware has also its advantages[1].
Definitely there would be a performance hit when the 4.5 mods were used, but someone who absolutely needed an old mod or whatever could do it. Microsoft caters too much to legacy code, and we all know how bad that has been. Apple changed too often, hurting business, but then the tech got better and they wised up--people now can emulate their old software on a Mac if they're willing to take a performance hit. This is where Drupal should go if technically possible-
IMHO it is not. And even if it were possible, I wouldn't deem it desirable. And even if you don't care about my opinion you still need to find somebody who writes the code for this.
-and hey, this is a way that legacy support BECOMES a technical innovation. If an API-engine concept was developed, Drupal probably would have my heart for life. :-)
Just keep it, sorry.
3) An easy way for less technical people to know the stability of a contributed module. Some modules are constantly being improved, and there is no doubt they will update with each new Drupal release. Other modules are close to dormant, and there's a good chance they are Drupal version specific because they're a niche module and the creator doesn't really support it any longer. As a business person, I need to have at least a sense which modules I can rely upon--I might go with Drupal if mailhandler is updated regularly, but I'll probably pass on Drupal if it really only is a 4.6 module. Worse, I might go with Drupal then curse the community if I think mailhandler is a long-term module and it goes away in 4.7.
It is open source, it _can't_ go away (as long as anybody still has a copy).
There are ways to get a sense for this if you're experienced, but I think a lot of new or non-technical users can't see the signals--and no, they also can't adopt the project(s) if they foolishly rely on a 4.6-only mod. We need a warning system that gauges risk. I'd be more than happy to lay out ideas on this if others are interested.
Let me give you all a few hints what I do to check the activity and usefulness of a contributed module: 1) I check who the author and /or current maintainer is. If it is a long time Drupal contributor or somebody who frequently contributes patches to Drupal core, then I am quite sure I can use it, or I can at least send him patches for problems I encounter as he is likely to be very interested in improving Drupal. 2) Of course I also check the activity record of the module. There are two ways to do that: a) check the CVS commit messages (and their dates), eg: http://drupal.org/cvs?file=/modules/epublish/epublish.module b) check the general statistics of open issues for the project: http://drupal.org/project/issues/statistics 3) if an author is unknown to me, I might want to read the code, if that won't help you, you can check the code checker report: http://drupal.org/files/projects/epublish.status (this used to be linked from the project page, apparently we need to add it again) A script tries some basic analysis of the code. This is /very/ basic and should not instill a false sense of safety in you. Anybody is welcome to help us improve that script, it is in the tricks directory in contrib.
I can tell you it¹s in your best interest, and your customer¹s best interest, to keep up with current releases, and fix/rebuild anything build on old releases as opposed to trying to protect the investment it¹s definitely a false safety.
Any site that uses a contrib module has to wait for that module to be updated, OR pay for someone to update it, OR update it themselves.
Money is a factor for open source adoption, too--a lot of non-profits that can't afford commercial CMSes use open source instead. OSS also is gaining a following in less developed countries because anyone can get the software (not just because anyone can develop it).
I see open source as being more than just about technological innovation at this point. It is many things to many people--and a common one is its use as a cheaper alternative. I don't want to damn all these folks who need it but can't afford to hire a consultant or learn the skills to do it themselves. Software is for the technical user, first and foremost--but the breakthrough OSS projects have been those that reach and help a wider market. And, I'd like to think this wider market often helps improve the software in the long run, too.
Drupal has a very wide market and there are consultants from a lot of countries who might work to local tariffs. I also attribute this to the fact that it can run on not too recent hardware (see [1]). You can't really have both. Either you have a lightning fast application which serves the needs of many people or you have a behemoth which is so backwards compatibly you can't run Drupal on a decent webserver anymore. If you want the latter, I recommend to look at several Java applications... Also, you don't really need to pay a consultant to get a module updated. Often there are more people interested in a module and one of them might even be able to update it. Sure, this won't be available on the same day that the new core version is available, but that isn't really important. I have never gotten so many contributed patches for my contributed modules than after this 4.7 release. True, most patches required extra work by me, but they at least did part of it. Cheers, Gerhard
On May 30, 2006, at 9:31 AM, Peter Kowalke wrote:
3) An easy way for less technical people to know the stability of a contributed module.
http://drupal.org/node/63491 comments, UI proposals, and patches are welcome. thanks, -derek (dww)
2006/5/30, Peter Kowalke <peter2005@kowalke.info>:
Some OSS projects are healthy and business friendly. Why can't Drupal be one of theme? The best technical products don't usually win in the end--the winners are the best technical products that ALSO cater to businesses and laymen. How can Drupal thrive and grow like a mySQL or a Linux or a PHP? Technical innovation is part of the answer, but not all of it.
From my point of view, Drupal is healthy and business friendly (it is
for mine).
Amen to a clearly labeled and easy to use archive where those too poor, too stupid, too contented or too technically shaky can continue to use their old Drupal installations. Let the community march on, but without burning or hiding what came before.
I'd like to see a http://archive.drupal.org/ for anything 4.5 and below.
Why not ? I have to agree that many non-techie persons are afraid of CSV or SVN despite the existance of easy good..
If Drupal is going to press ever onward with technical innovation, which it should, it needs more than just a well-marked archive. From a business mindset it needs:
1) A really easy upgrade path. Maybe an auto-update feature--although I know that gets sticky really fast given homemade modules...there would need to be a lot of thought on how to do it sanely.
Upgrading will be easier in the future (install file for modules and own directories, etc) But again, it can't be backported to older versions :(
2) If not an unchanging API, then an API abstraction layer of some kind.
That's the way of the new FormAPI and that's why it break compatibily so... But from now (4.7), it's easier for modules makers to build a form and it can no longer break even if fonctionalities are added.. There's also a debate now about abstracting the DB. Of course it won't be as complete as pearDB, but it would face most cases without performance loose.
Wouldn't it be great if a 4.5 user could install an API-engine of sorts that would allow him to run 4.5 modules and stuff on a newer install? Definitely there would be a performance hit when the 4.5 mods were used, but someone who absolutely needed an old mod or whatever could do it. Microsoft caters too much to legacy code, and we all know how bad that has been. Apple changed too often, hurting business, but then the tech got better and they wised up--people now can emulate their old software on a Mac if they're willing to take a performance hit. This is where Drupal should go if technically possible--and hey, this is a way that legacy support BECOMES a technical innovation. If an API-engine concept was developed, Drupal probably would have my heart for life. :-)
LOL An PHP web based app cannot be compared to an native (binary) OS app. Drupal is not serlets, sorry.
On May 29, 2006, at 10:26 PM, blogdiva@culturekitchen.com wrote:
Which is why upgrading is costly. When you've tweaked things in 20, 30, 50 heres and theres, writing over them for the next decimal upgrade becomes prohibitive. It's time and money gone completely out of the window.
you should read http://drupal.org/node/5123 yes, if you're not "a developer" you might not know much about CVS yet. but using a revision control system to keep track of your changes is a wonderfully powerful solution to this problem once you get used to it. this page details exactly what you need to know to let another piece of software take care of all your tweaks, and apply them to the latest version of drupal that comes out. it doesn't do *all* of the work for you, but chances are good it will save you a lot of time. if you're so interested in the history of things like the drupal source, you should definitely keep track of the history of your own modifications to that source, too. enjoy, -derek (dww)
Op dinsdag 30 mei 2006 07:26, schreef blogdiva@culturekitchen.com:
Which is why upgrading is costly. When you've tweaked things in 20, 30, 50 heres and theres, writing over them for the next decimal upgrade becomes prohibitive. It's time and money gone completely out of the window.
Well, I, developing full time with Drupal for a few years already, wanted to upgrade my blog (as the first of twelve+ sites). Its a blog. stories, images, taxonomy and comments. a very simple site. Should be a 5 minute job, I thought. I was like: « If I dont upgrade ill be stuck here forever» Which is what Lambert points out too. And that was the only valid reason for upgrading I could think of. However "something" horribly broke. during the upgrade all content was lost (I have backups), and I really did not feel like searching for the problem longer then 30 minutes. I don't even feel like getting/asking support, because the One solution is very simple, and costs ZERO time: stay where I am. It works perfectly fine, has done so for nearly one and a half year. I can upgrade. Offcourse I can. Maybe I should. But «Why fix and break something that aint broken?» Only because that allows me the latest nittygritty? When this happens, even when I expect the upgrade to cost time/money/frustration, I feel like «never mind». When upgrading costs me such a lot of hassle, staying where I am IS the best solution. And A hassle it is. Always. Themes break, customised modules break, modules are not available, you name it. We should not pretend that upgrading is Very Easy. Academically seen it may be. But in practice there is always more to it then you expect (Murphy, people, Murphy!) and because it is Drupal -infinite flexibility- people hardly ever run vanilla sites. And when my practical example above shows that even a vanilla Drupal is not safe from Murphy, how will a highly modified (as in with loads of modules) site react on an upgrade? So for a lot of people staying put is the cheapest, hassle-free, stressless, and therefore BEST solution. I have found that most of the (very un-tech-savvy) clients of mine prefer NOT to upgrade, but rather include an upgrade in a general overhaul of the site. If they dont need that overhaul, they dont need upgrading. Bèr
On 30 May 2006, at 10:14, Bèr Kessels wrote:
However "something" horribly broke. during the upgrade all content was lost (I have backups), and I really did not feel like searching for the problem longer then 30 minutes. I don't even feel like getting/asking support, because the One solution is very simple, and costs ZERO time: stay where I am. It works perfectly fine, has done so for nearly one and a half year. I can upgrade. Offcourse I can. Maybe I should. But «Why fix and break something that aint broken?» Only because that allows me the latest nittygritty?
Sure, you don't have to upgrade the instant a new Drupal version comes out, but ultimately, you'll have to upgrade. Saying that not upgrading doesn't cost you anything ('ZERO time') is false. It might be true in very specific situations, but if you think that this is true in general, you are being short-sighted. Re-read Jonathan's last mails to understand why. Or consider this simple example: your current Drupal installation requires PHP version X. Three years from now, the PHP team fixes an important security bug. To keep your server secure, you'll have to upgrade your PHP installation to version Y. Unfortunately, your old Drupal installation will not run on PHP version Y, and suddenly you are faced with a very expensive upgrade scenario. -- Dries Buytaert :: http://www.buytaert.net/
Op dinsdag 30 mei 2006 10:39, schreef Dries Buytaert:
Saying that not upgrading doesn't cost you anything ('ZERO time') is false. It might be true in very specific situations, but if you think that this is true in general, you are being short-sighted. Re-read Jonathan's last mails to understand why.
Yes. But dont forget that maintainance == costing too. (where costs can be anything from frustration till money). And as long as maintainance costs little, then upgrading is always more expencive. Staying with 4.6 for a period of time, also does not mean "forever". Because as soon as maintainance starts to cost more (for a 4.5 this will be the case) then upgrading might be the better option. Depending on the costs of that upgrade. I reread Jonathans posts twice, becuase this problem really interests me (I studied operational engineering: Maintaining and upgrading large technical facilities such as powerplants) . Translating this to the IT world makes it even more interesting for me. I made a large spreadsheet wich shows me when "maintaining old stuff" is costing me money. As well as how much more upgrades will cost over time. Outcome: Some sites must stay put, maybe forever, since they simply generate less happyness ATM then an upgrade will costs. But others are far better off with upgrading. some even need a mayor overhaul every release/half year. and, last, something I havent heard yet, is the Adaptation costs: An upgrade requires learning new code. New interfaces. Requires education for the editors. But above all it brings in the chance that you will loose yout audience, if they dont like what you have brought them after the upgrade. In any case: All I wanted to say, is that either saying "upgrade or your site will die" as well as "stay put at all costs, because upgrading costs more then you might imagine" is shortsighted. Both have just as valid points. Both are usefull for different people in different situations. But we are all chiming the same here (or whatever that saying is): No-one keeps people from running old stuff: Dries does not even mind facilitating people that want to keep 4.5 going! While the main focus lies on a progressing HEAD, to keep that up to date. Bèr
But «Why fix and break something that aint broken?»
Because you think it isn't broken, doesn't mean it isn't actually broken. When someone discovers a security bug (be it in Drupal, PHP or Apache), all of a sudden your site is broken. When that happens, being able to upgrade matters a lot. -- Dries Buytaert :: http://www.buytaert.net/
Hi, Also it your still really need to get access to 4.5 you can still check it out of CVS. Gordon. Morbus Iff wrote:
Why do you need to remove this stuff? There are those who like I have
Leaving it up is, to some, an admission of *support*. We no longer support 4.5 - we won't answer questions about it, help people with it, or blah blah blah. The strongest way we can say this is to remove the downloads in their entirety. You are more than welcome, however, to mirror the download on your own site or hard drive. Just realize that any request for help will fall on deaf ears.
If you want to, you can still use the files from CVS tagged with DRUPAL-4-5. They won't be deleted. 2006/5/27, blogdiva@culturekitchen.com <blogdiva@culturekitchen.com>:
Noooooooooooooo!
Why do you need to remove this stuff? There are those who like I have not upgraded yet to 4.6 and are not necessarily in a hurry to jump to 4.7. If for any reason, you should leave things as they are for people who, like me, are jinxed enough to maybe have to do a clean install of 4.5 before going on to the upgrade.
I am just paralyzed about upgrading. I have yet to see any good step- by-step on how to do this. So please, don't move anything that people like me may have to use during the countless hours it will take to go up a decimal point.
/ liza sabater, publisher culturekitchen network
On 27.May.2006, at 09:28, Gerhard Killesreiter wrote:
Hi there!
As of the last security release Drupal 4.5 is de facto unsupported. Contributed modules and themes are already no longer repackaged (don't know who changed that and when). I plan to remove the existing tarballs from files/projects so that they are no longer for download. Please voice your objections soon (and you better have very good reasons ;).
Cheers, Gerhard
blogdiva@culturekitchen.com wrote:
I am just paralyzed about upgrading. I have yet to see any good step-by-step on how to do this. There's usually one in INSTALL.TXT of the new version you're upgrading too, what else do you need?
So please, don't move anything that Note that old versions never disappear from the CVS repository, only the tarballs and associated stuff on drupal.org itself are taken down. You can still get them, just a little bit more work is involved.
-- Adrian Simmons (aka adrinux) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@perlucida.com>
On Sat, May 27, 2006 at 03:28:21PM +0200, Gerhard Killesreiter wrote:
Hi there!
As of the last security release Drupal 4.5 is de facto unsupported. Contributed modules and themes are already no longer repackaged (don't know who changed that and when). I plan to remove the existing tarballs from files/projects so that they are no longer for download. Please voice your objections soon (and you better have very good reasons ;).
Cheers, Gerhard
Why not keep them for historical purposes ? Maybe create an "Archived releases" section somewhere and keep them there ?? -- GNU/Linux registered user #224950 Proud Egyptian GNU/Linux User Group <www.eglug.org> Member. Life powered by Debian, Homepage: www.foolab.org -- Don't send me any attachment in Micro$oft (.DOC, .PPT) format please Read http://www.gnu.org/philosophy/no-word-attachments.html Preferable attachments: .PDF, .HTML, .TXT Thanx for adding this text to Your signature
On Saturday 27 May 2006 12:24, Khalid B wrote:
Why not keep them for historical purposes ? Maybe create an "Archived releases" section somewhere and keep them there ??
They can always be checked out from the CVS repository using the DRUPAL-4-5 tag.
If you're not a developer, CVS access means bupkis to you. I have to agree with Lisa on this one. Whether we like it or not, Drupal has evolved from an open source project into an open source product. That means we do need to pay attention to things like PR, support, customer relations, etc. Marketing comes automatically if those are done correctly (ah, the wonders of the Internet). The fact that we mention 4.5 on the site doesn't automatically mean that we have to provide extensive support and upgrades for it. As long as it is properly marked as such, then it can be a convenience service but an important one. Say: - Development release: (CVS snapshot) - Current release: (latest 4.7-tagged version) - Legacy release: (latest 4.6-tagged version) - Archived releases: (any old tarballs from previous tags) And then describe on the page that devs should use Devel version, everyone else should use Current, Legacy is for security patches only, and Archived is "unsupported, but provided as a convenience". Remember, 4.5 isn't that old. It was the stable version at the beginning of last year. I know a government office that is using a 4.6 site I built for them last fall as an internal application. I'd hate for them to suddenly be unable to even find 4.6-targeted modules this fall when 4.7++ is released and we go through this routine again. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Larry Garfield wrote:
On Saturday 27 May 2006 12:24, Khalid B wrote:
Why not keep them for historical purposes ? Maybe create an "Archived releases" section somewhere and keep them there ??
They can always be checked out from the CVS repository using the DRUPAL-4-5 tag.
If you're not a developer, CVS access means bupkis to you.
I have to agree with Lisa on this one. Whether we like it or not, Drupal has evolved from an open source project into an open source product. That means we do need to pay attention to things like PR, support, customer relations, etc. Marketing comes automatically if those are done correctly (ah, the wonders of the Internet).
I personally had preferred that we had mentioned the fact that 4.5 is discontinued explicitly in the security advisories, although I am not sure they are an appropriate place for this. Maybe somebody wants to write an obituary.
The fact that we mention 4.5 on the site doesn't automatically mean that we have to provide extensive support and upgrades for it. As long as it is properly marked as such, then it can be a convenience service but an important one.
No. Who would want to download these files? People who have a 4.5 site already have the files. Nobody else has any reason to download them. People should upgrade since Drupal 4.5 is insecure. If the removal of downloadable contrib modules for 4.5 serves as an incentive to get them going, I consider this an even better idea.
Say:
- Development release: (CVS snapshot) - Current release: (latest 4.7-tagged version) - Legacy release: (latest 4.6-tagged version) - Archived releases: (any old tarballs from previous tags)
And then describe on the page that devs should use Devel version, everyone else should use Current, Legacy is for security patches only, and Archived is "unsupported, but provided as a convenience".
It is merely confusing. I'd surprised if you still could buy or download discontinued versions of commercial software if that is what you want to compare Drupal to.
Remember, 4.5 isn't that old. It was the stable version at the beginning of last year.
In Drupal terms this is very old, sorry to say so. This past release cycle took over a year which is an exceptionally long development period wrt Drupal. We used to have two, and once even three releases per year.
I know a government office that is using a 4.6 site I built for them last fall as an internal application. I'd hate for them to suddenly be unable to even find 4.6-targeted modules this fall when 4.7++ is released and we go through this routine again.
They will still be able to find them through our web interface to CVS. Maybe they should speak to you about an upgrade... Interested parties wil observe that there aren't any earlier releases than 4.5 listed on drupal.org. Our policy was always to support the latest two releases. If we do support, then we offer tarballs, if we don't we don't. Unless something better comes up, I will remove the files tomorrow. Cheers, Gerhard
They will still be able to find them through our web interface to CVS. Maybe they should speak to you about an upgrade...
Interested parties wil observe that there aren't any earlier releases than 4.5 listed on drupal.org. Our policy was always to support the latest two releases. If we do support, then we offer tarballs, if we don't we don't.
Unless something better comes up, I will remove the files tomorrow.
No, you won't. I don't remember having deleted _any_ old releases. When did this become a policy? When where the other old releases deleted? Who decided this? IMO, it is better to keep old releases around. People with a clue know that these might be insecure. This is such basic knowledge that believing otherwise is almost insulting. If you deleted old releases (without asking), you deleted the original Drupal 1.0.0 and Drupal 2.0.0 release. These were not in CVS yet. I hope that these are still around! As I mentioned before, with enough people to help, I'd be happy to commit patches to the DRUPAL-4-5 and DRUPAL-4-6 branch. Whether it is officially maintained or not. -- Dries Buytaert :: http://www.buytaert.net/
On 28 May 2006, at 09:39, Dries Buytaert wrote:
No, you won't.
I don't remember having deleted _any_ old releases. When did this become a policy? When where the other old releases deleted? Who decided this?
Regardless of the answers, I do think it doesn't hurt to keep old releases around. * Insecure Linux kernels available for download at ftp://ftp.kernel.org/pub/linux/kernel * Insecure Firefox copies available for download at http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ -- Dries Buytaert :: http://www.buytaert.net/
Dries Buytaert wrote:
They will still be able to find them through our web interface to CVS. Maybe they should speak to you about an upgrade...
Interested parties wil observe that there aren't any earlier releases than 4.5 listed on drupal.org. Our policy was always to support the latest two releases. If we do support, then we offer tarballs, if we don't we don't.
Unless something better comes up, I will remove the files tomorrow.
No, you won't.
Right. This answer was about the only thing that could stop me.
I don't remember having deleted _any_ old releases. When did this become a policy? When where the other old releases deleted? Who decided this?
I have absolutely no idea. I had assumed it was you. I know that Drupal 3 and early 4 realeases were not available for quite some time. Probably before I got access to the infrastructure.
IMO, it is better to keep old releases around. People with a clue know that these might be insecure. This is such basic knowledge that believing otherwise is almost insulting.
You assume that people have a clue. That might be an error.
If you deleted old releases (without asking), you deleted the original Drupal 1.0.0 and Drupal 2.0.0 release. These were not in CVS yet. I hope that these are still around!
They are not, but I didn't delete them either. I had removed the Drupal 4.7 betas and RCs and contrary to what you said did not delete them but only moved them outside the htdocs tree.
As I mentioned before, with enough people to help, I'd be happy to commit patches to the DRUPAL-4-5 and DRUPAL-4-6 branch. Whether it is officially maintained or not.
I still think this is a bad idea, but your decision. I have removed most of the 4.5 modules that I released from distribution as I believe that the only other possibility would be to fix both 4.5 core and the modules. The first is probably not going to happen and I have no desire to do the latter. Cheers, Gerhard
Dries I am a bit confused. A while back we did a reorganization of the download area and removed all links to old releases, leaving only 4.5, 4.6, 4.7 and HEAD. Everything else was effectively retired by removing 4.4 and older from the drop down menus for issues, projects, ..etc. That was before 4.7 was out. Now that 4.7 is out, it is only normal to shift everything by one release, so 4.5 gets dropped from the lists. So, in conformance with what we did, the list here http://drupal.org/node/3060/release will show only CVS, 4.7.x and 4.6.x only, vs. 4.5.x only. If your objection is "old tarballs should not get deleted", and that by de-listing them, we effectively retire them, then I am fine by that. But, if you are saying that we have no policy of "retiring" old versions, then that goes against of what was done with everyone's involvement in the past.
On 5/28/06, Khalid B <kb@2bits.com> wrote:
Dries
I am a bit confused.
A while back we did a reorganization of the download area and removed all links to old releases, leaving only 4.5, 4.6, 4.7 and HEAD.
Everything else was effectively retired by removing 4.4 and older from the drop down menus for issues, projects, ..etc.
That was before 4.7 was out.
Now that 4.7 is out, it is only normal to shift everything by one release, so 4.5 gets dropped from the lists.
So, in conformance with what we did, the list here http://drupal.org/node/3060/release will show only CVS, 4.7.x and 4.6.x only, vs. 4.5.x only.
If your objection is "old tarballs should not get deleted", and that by de-listing them, we effectively retire them, then I am fine by that.
But, if you are saying that we have no policy of "retiring" old versions, then that goes against of what was done with everyone's involvement in the past.
[Hit send too soon.] If we want to modify the policy and say we need to keep 3 previous releases + HEAD, instead of 2 previous + HEAD, then that is fine as well, as long as it is stated to be so. A stated policy on (a) what is kept and (b) what is maintained (security fixes), will avoid confusion. Regards
Khalid B wrote:
On 5/28/06, Khalid B <kb@2bits.com> wrote:
Dries
I am a bit confused.
A while back we did a reorganization of the download area and removed all links to old releases, leaving only 4.5, 4.6, 4.7 and HEAD.
Everything else was effectively retired by removing 4.4 and older from the drop down menus for issues, projects, ..etc.
That was before 4.7 was out.
I am not sure when this was. The old tarballs starting with 4.0.0 are actually still available for download if you know the url. They have been removed from project/files and thus project.modules does not pick them up anymore. Where earlier releases are stored I don't know. A page from the internet archive shows that 3.0 wasn't available for download anymore in 2003. http://web.archive.org/web/20031011080644/http://drupal.org/project/drupal It is possible they never made the transition to the new hardware. I've never seen the mythical Drupal 1.0 tarball myself. What we did shortly after the 4.7 release was to move the old betas and rcs outside of project/files. Cheers, Gerhard
On 5/28/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Khalid B wrote:
On 5/28/06, Khalid B <kb@2bits.com> wrote:
Dries
I am a bit confused.
A while back we did a reorganization of the download area and removed all links to old releases, leaving only 4.5, 4.6, 4.7 and HEAD.
Everything else was effectively retired by removing 4.4 and older from the drop down menus for issues, projects, ..etc.
That was before 4.7 was out.
I am not sure when this was.
Was before May 1, 2006 for sure, although by a long time. Contrib had the DRUPAL-4-7 tag at that time, and some modules were available, but drupal 4.7 itself was not out.
The old tarballs starting with 4.0.0 are actually still available for download if you know the url. They have been removed from project/files and thus project.modules does not pick them up anymore. Where earlier releases are stored I don't know.
So, are we going to extend that to the current situation? i.e. we only have 4.6, 4.7, and CVS (HEAD) listed in the project and leave the tarballs where they are, but less chance of getting them from a current linking page?
What we did shortly after the 4.7 release was to move the old betas and rcs outside of project/files.
Yes, but we did something else a while back for pre-4.5 releases in project and issues.
Khalid B wrote:
On 5/28/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Khalid B wrote:
On 5/28/06, Khalid B <kb@2bits.com> wrote:
Dries
I am a bit confused.
A while back we did a reorganization of the download area and removed all links to old releases, leaving only 4.5, 4.6, 4.7 and HEAD.
Everything else was effectively retired by removing 4.4 and older from the drop down menus for issues, projects, ..etc.
That was before 4.7 was out.
I am not sure when this was.
Was before May 1, 2006 for sure, although by a long time.
Contrib had the DRUPAL-4-7 tag at that time, and some modules were available, but drupal 4.7 itself was not out.
The old tarballs starting with 4.0.0 are actually still available for download if you know the url. They have been removed from project/files and thus project.modules does not pick them up anymore. Where earlier releases are stored I don't know.
So, are we going to extend that to the current situation? i.e. we only have 4.6, 4.7, and CVS (HEAD) listed in the project and leave the tarballs where they are, but less chance of getting them from a current linking page?
Ask Dries.
What we did shortly after the 4.7 release was to move the old betas and rcs outside of project/files.
Yes, but we did something else a while back for pre-4.5 releases in project and issues.
That is probably the reason why they are where I found them. Cheers, Gerhard
On 28 May 2006, at 18:11, Khalid B wrote:
A while back we did a reorganization of the download area and removed all links to old releases, leaving only 4.5, 4.6, 4.7 and HEAD.
I'm not saying we are going to support Drupal 4.5 now Drupal 4.7 has been released. Drupal 4.5 is not officially supported. However, I don't mind committing patches against the Drupal 4.5 branch if there are enough people providing and testing patches. I'm just saying that we should leave the old files in place. We don't have to link to these files from the download pages, nor do we have to "promote" these files. However, it is nice if old links (eg. the links in the official Drupal 4.5.x announcements) don't break. The old files will continue to be available at http://ftp.osuosl.org/ pub/drupal/files/projects/. It is not as accessible as it used to be, but that's OK. What matters is that the files are still there for those who really want them. -- Dries Buytaert :: http://www.buytaert.net/
On Sat, May 27, 2006 at 01:24:57PM -0400, Khalid B wrote:
Why not keep them for historical purposes ? Maybe create an "Archived releases" section somewhere and keep them there ??
They can always be checked out from the CVS repository using the DRUPAL-4-5 tag.
I understand they can be checked out. But why complicate things ? -- GNU/Linux registered user #224950 Proud Egyptian GNU/Linux User Group <www.eglug.org> Member. Life powered by Debian, Homepage: www.foolab.org -- Don't send me any attachment in Micro$oft (.DOC, .PPT) format please Read http://www.gnu.org/philosophy/no-word-attachments.html Preferable attachments: .PDF, .HTML, .TXT Thanx for adding this text to Your signature
Mohammed Sameer wrote:
On Sat, May 27, 2006 at 01:24:57PM -0400, Khalid B wrote:
Why not keep them for historical purposes ? Maybe create an "Archived releases" section somewhere and keep them there ??
They can always be checked out from the CVS repository using the DRUPAL-4-5 tag.
I understand they can be checked out. But why complicate things ?
Why offer things for download that a) are insecure to use and b) nobody needs anymore? Cheers, Gerhard
On Sat, May 27, 2006 at 08:09:41PM +0200, Gerhard Killesreiter wrote:
Mohammed Sameer wrote:
On Sat, May 27, 2006 at 01:24:57PM -0400, Khalid B wrote:
Why not keep them for historical purposes ? Maybe create an "Archived releases" section somewhere and keep them there ??
They can always be checked out from the CVS repository using the DRUPAL-4-5 tag.
I understand they can be checked out. But why complicate things ?
Why offer things for download that a) are insecure to use and b) nobody needs anymore?
I agree that they are insecure, But sometimes you needn't care much about security. What if I'm using it as an internal system for an office. And that system is not exposed ? Is the security the main concern here ? Yes I'd still worry about security but I can lower the priority of such thing. I'd say that we keep it for historical purpose, It's the same why previous releases of many FOSS software are kept. -- GNU/Linux registered user #224950 Proud Egyptian GNU/Linux User Group <www.eglug.org> Member. Life powered by Debian, Homepage: www.foolab.org -- Don't send me any attachment in Micro$oft (.DOC, .PPT) format please Read http://www.gnu.org/philosophy/no-word-attachments.html Preferable attachments: .PDF, .HTML, .TXT Thanx for adding this text to Your signature
On 5/27/06, Gerhard Killesreiter <gerhard@killesreiter.de> wrote:
Mohammed Sameer wrote:
I understand they can be checked out. But why complicate things ?
Why offer things for download that a) are insecure to use and b) nobody needs anymore?
Yeah. Donald Norman makes the canonical argument on this point in his Design of Everyday things. Your design should generally endeavor to make tasks easy for users. The major exception is that if something is dangerous or has a low likelihood of being what the user wants, you should use the design principles to purposefully make that task *hard* to do. There is a good reason you keep the poison in a bottle that is hard to open and then put scary labels on them and then hide them in a locked cupboard. So it is with unmaintained versions of software. Dries has said that if someone wants to maintain past releases they are welcome to make that plea to him but they must make a good case for being able to actually support it (e.g. create/examine/review security problems and patches). Regards, Greg
Op zaterdag 27 mei 2006 20:09, schreef Gerhard Killesreiter:
b) nobody needs anymore?
I guess this is the whole point. You state this as a fact, while a lot of people think they do still need this. I know for myself that I will be needing 4.6.X for a long time. Bèr
participants (24)
-
Adrian Simmons -
blogdiva＠culturekitchen.com -
Bèr Kessels -
Derek Wright -
Dries Buytaert -
Dries Buytaert -
Earl Dunovant -
Earl Miles -
Fernando Silva -
Gabor Hojtsy -
Gerhard Killesreiter -
Gildas Cotomale -
Gordon Heydon -
Greg Knaddison - GVS -
Jonathan Lambert -
Karoly Negyesi -
Khalid B -
Konstantin Käfer -
Larry Garfield -
Mohammed Sameer -
Morbus Iff -
Peter Kowalke -
Richard Archer -
sime