Hello world, just to let you know that we branched Drupal core. There is now a DRUPAL-5 branch that will be maintained by Neil Drumm, with help from Steven and me. (http://buytaert.net/neil-drumm) This also means that CVS HEAD is open for development again, and that - after a long code freeze - we can finally start working on Drupal 6. Yay! (I'm going to create a new thread to discuss Drupal 6 later this week.) I haven't assigned a Drupal 6 core maintainer yet. A new core maintainer is not a requirement, but I'll probably assign one in a couple of weeks, once we're a little bit further down the road. Rock on, -- Dries Buytaert :: http://www.buytaert.net/
Praise Druplicon! Time to start fixing postponed patches. Also, now that there is a DRUPAL-5 branch, api.drupal.org needs a Drupal 5.0 version and the contributor block (new organization looks great btw) should link to the 5.x-dev tarball. Dries Buytaert wrote:
Hello world,
just to let you know that we branched Drupal core. There is now a DRUPAL-5 branch that will be maintained by Neil Drumm, with help from Steven and me. (http://buytaert.net/neil-drumm)
This also means that CVS HEAD is open for development again, and that - after a long code freeze - we can finally start working on Drupal 6. Yay! (I'm going to create a new thread to discuss Drupal 6 later this week.)
I haven't assigned a Drupal 6 core maintainer yet. A new core maintainer is not a requirement, but I'll probably assign one in a couple of weeks, once we're a little bit further down the road.
Rock on,
-- Dries Buytaert :: http://www.buytaert.net/
Chris Kennedy wrote:
Also, now that there is a DRUPAL-5 branch, api.drupal.org needs a Drupal 5.0 version and the contributor block (new organization looks great btw) should link to the 5.x-dev tarball.
I'll be working on that sometime in the next few days. It isn't much of a problem yet. Any objections to removing 4.6 from api.drupal.org soon? -- Neil Drumm http://delocalizedham.com/
On 1/16/07, Neil Drumm <drumm@delocalizedham.com> wrote:
Any objections to removing 4.6 from api.drupal.org soon?
Personally, I'd like to leave it up there until the next release. I'm not doing much support on 4.6 these days, but on the rare occasions that I do need to having the API online is invaluable. I feel like 4.7 to 5.0 is a pretty simple transition but 4.6 to 4.7 had a bunch of function changes. At this point, unless I'm offline, when I've got a question about a function, I don't bother searching the Drupal source, I just hit up api.d.o. andrew
I think that api should always keep old versions, because we never know when we need to do support for old sites. On 1/16/07, Neil Drumm <drumm@delocalizedham.com> wrote:
Chris Kennedy wrote:
Also, now that there is a DRUPAL-5 branch, api.drupal.org needs a Drupal 5.0 version and the contributor block (new organization looks great btw) should link to the 5.x-dev tarball.
I'll be working on that sometime in the next few days. It isn't much of a problem yet.
Any objections to removing 4.6 from api.drupal.org soon?
-- Neil Drumm http://delocalizedham.com/
On Tuesday 16 January 2007 15:55, Fernando Silva wrote:
I think that api should always keep old versions, because we never know when we need to do support for old sites.
+1 here. I still have a couple of sites running Drupal 4.5, and a couple running 4.6, even though most of mine now run 4.7. It's not always practical to keep up with the latest release, however desirable that may be. Sometimes the decision to upgrade isn't just in the hands of the site admin. Mark it deprecated, move it to another subdomain, or whatever, but please don't take it offline. Disk space is cheap. Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
Are there any reasons for actually removing it ? Module devs looking to upgrade their modules have less difficulty matching form_* to FAPI while the 4.6 docs are still there, for instance: do you remember offhand the order of the parameters to these ? And why force them to maintain their own doc repository or read the code ? ----- Original Message ----- From: "Neil Drumm" <drumm@delocalizedham.com> To: <development@drupal.org> Sent: Tuesday, January 16, 2007 9:48 PM Subject: Re: [development] Core: DRUPAL-5 branched [...]
Any objections to removing 4.6 from api.drupal.org soon? [...]
On Jan 16, 2007, at 12:55 PM, FGM wrote:
Are there any reasons for actually removing it ?
agreed. i'd vote in favor of keeping 4.6 there. it's not like any of the UI bits on api.d.o would become monstrously difficult to navigate with 4 versions of core to choose from. while we're on the subject, can we please stop using "HEAD" on api.d.o for anything? the handbooks are now full of stale links to api.d.o since HEAD is about to move again (especially in the module/ theme update pages). we know what the next version is going to be, so there's no need for the level of indirection anymore (and it's causing problems). as we start the "upgrading modules from 5.x to 6.x" page, let's link directly to http://api.drupal.org/api/6.x/function/hook_menu instead of: http://api.drupal.org/api/HEAD/function/hook_menu i'm pretty sure hunmonk already implemented all of this, it's just a question of installing it on api.d.o. thanks, -derek
Derek Wright wrote:
On Jan 16, 2007, at 12:55 PM, FGM wrote:
Are there any reasons for actually removing it ?
agreed. i'd vote in favor of keeping 4.6 there. it's not like any of the UI bits on api.d.o would become monstrously difficult to navigate with 4 versions of core to choose from.
That is what I expected. 4.6 is now unsupported, maybe there should be a drupal_set_message(t('deprecated/unsupported...')).
http://api.drupal.org/api/6.x/function/hook_menu
instead of:
http://api.drupal.org/api/HEAD/function/hook_menu
i'm pretty sure hunmonk already implemented all of this, it's just a question of installing it on api.d.o.
Its not really implementation, just getting the files and configuration. I could change it now if I wanted to break everyone's bookmarks, but I don't. It will be something closer to http://api.drupal.org/api/function/hook_menu/6.x Anyone want to help out with some .htaccess rewrite rules? I'm not going to change around the URLs without them. -- Neil Drumm http://delocalizedham.com/
Indeed, since all answers simultaneously mentioned that it was better to keep it online, and that this was for maintenance of older sites or migrations to more recent versions, including a specific obsolescence warning on the 4.6 pages makes perfect sense. ----- Original Message ----- From: "Neil Drumm" <drumm@delocalizedham.com> To: <development@drupal.org> Sent: Wednesday, January 17, 2007 12:57 AM Subject: Re: [development] Core: DRUPAL-5 branched
Derek Wright wrote:
On Jan 16, 2007, at 12:55 PM, FGM wrote:
Are there any reasons for actually removing it ?
agreed. i'd vote in favor of keeping 4.6 there. it's not like any of the UI bits on api.d.o would become monstrously difficult to navigate with 4 versions of core to choose from.
That is what I expected. 4.6 is now unsupported, maybe there should be a drupal_set_message(t('deprecated/unsupported...')). [...]
On Jan 16, 2007, at 3:57 PM, Neil Drumm wrote:
I could change it now if I wanted to break everyone's bookmarks, but I don't.
you're going to break everyone's links as soon as you change HEAD to point to the 6.x API no matter what you do. that's exactly the point of why we shouldn't use HEAD any more. what are you planning to redirect HEAD links to? 5.x? 4.7.x? no matter what you do, it'll be wrong for some existing links. i say just break the links, since they're already doomed. ;) then, when people repair their links, they'll be forced to correctly point to the version they originally intended, and life will be better in the end.
It will be something closer to http://api.drupal.org/api/function/ hook_menu/6.x
out of curiosity, why? a) how is that better than having the version right next to the "api" part of the URL? (and why break existing links that do point to specific version -- or force yourself to do url re-writing tricks to get the old links to still work?) b) how would you view a listing of all functions in a given core API version? for example: http://api.drupal.org/api/4.7/function would that become: http://api.drupal.org/api/function/5 seems a little wonky, since then sometimes it's a function name that comes after "function", and sometimes a version. c) not all functions exist in all versions of the API, so it seems weirder to me conceptually to have the version last (thinking of it like a tree). what would exist at: http://api.drupal.org/api/function/hook_menu (w/o a version)? would that show you the "current" version of the API's docs for that function (eek). what if the function has been deprecated in the current version of the api, for example: http://api.drupal.org/api/function/hook_settings ?? seems like trouble, but then again, i've never looked at api.module, and am probably missing many important details. however, i don't care that much. so long as HEAD is totally gone from api.d.o, i'll be happy. ;) thanks, -derek
Derek Wright wrote:
On Jan 16, 2007, at 3:57 PM, Neil Drumm wrote:
I could change it now if I wanted to break everyone's bookmarks, but I don't.
i say just break the links, since they're already doomed. ;) then, when people repair their links, they'll be forced to correctly point to the version they originally intended, and life will be better in the end.
A page with documentation, and links to other versions, is better than a 404.
It will be something closer to http://api.drupal.org/api/function/hook_menu/6.x
out of curiosity, why?
Local tasks are picky about their paths. -- Neil Drumm http://delocalizedham.com/
Quoting Derek Wright <drupal@dwwright.net>:
On Jan 16, 2007, at 3:57 PM, Neil Drumm wrote:
It will be something closer to http://api.drupal.org/api/function/ hook_menu/6.x
out of curiosity, why?
Apologies for butting in but I like the version after idea. The URI api/function/hook_menu could give a summary of the function including the significant changes per version while api/function/hook_menu/6.x could give the specifics for that version. It provides a cleaner interface to the user. Sounds like a lot of work though and don't know that it would be worth the amount of time. Earnie
I got a couple cents on this. E-Commerce has its own API setup for the time being. When we updated to the latest API module a while back we got these tabs. My first though was WTH is going on? But after about a minute of use I found it to be very intuitive and actually easier to navigate. It also made comparing the difference between functions in different version a snap which I didn't realize would be a feature I might need until it was there. So personally, I think its a great change based on my experience with it. I also think it will lead to better uses of api.drupal.org. James
On 1/18/07, James Gilliland <neclimdul@gmail.com> wrote:
I got a couple cents on this. E-Commerce has its own API setup for the time being. When we updated to the latest API module a while back we got these tabs. My first though was WTH is going on? But after about a minute of use I found it to be very intuitive and actually easier to navigate. It also made comparing the difference between functions in different version a snap which I didn't realize would be a feature I might need until it was there.
So personally, I think its a great change based on my experience with it. I also think it will lead to better uses of api.drupal.org.
James
Oh, and why is this discussion still attached to the branch thread? I'm never going to find it in 2 months when I want to look back at it.
Neil Drumm wrote:
Chris Kennedy wrote:
Also, now that there is a DRUPAL-5 branch, api.drupal.org needs a Drupal 5.0 version and the contributor block (new organization looks great btw) should link to the 5.x-dev tarball.
I'll be working on that sometime in the next few days. It isn't much of a problem yet.
Any objections to removing 4.6 from api.drupal.org soon?
I still use it. I don't think it costs us much to have it there. If you take it down I'll have to create my own (which isn't that big a deal, and in fact I'm working toward setting up api.module to track our own codebase).
participants (15)
-
Adam Cooper -
andrew morton -
Chris Kennedy -
Darrel O'Pry -
Derek Wright -
Dries Buytaert -
Earl Miles -
Earnie Boyd -
Fernando Silva -
FGM -
James Gilliland -
Khalid B -
Neil Drumm -
Rowan Kerr -
Syscrusher