Hi, Any body help me out on below issue. I have successfully installed Drupal 6.1 in my local environment but I am not able to create own regions.Please help me out. Regards, Surya ----- Original Message ----- From: "Steven Jones" <darthsteven@gmail.com> To: <development@drupal.org> Sent: Thursday, March 06, 2008 3:12 PM Subject: Re: [development] New functionality on project nodes installed ond.o

Wow, that's very fab.

Just a minor nitpick: The images on the RHS of the table for dev snapshots have an alt and title attribute of 'error', but there isn't any error going on. Maybe a text like:' Snapshots are for development only, NOT for production servers' or somesuch.

Otherwise great work.

On 06/03/2008, Derek Wright <drupal@dwwright.net> wrote:

...

If you own any project nodes on d.o please read this...

I just finished up a patch[1] that was holding up a string of improvements to project nodes. The most important new functionality is that you now have more fine grained control over what releases are displayed on your project nodes[2].

First of all, for each version of core, you now have separate controls for every major version, where you can specify if that core/ major combination is supported, and if you want a dev snapshot displayed for it or not. Then, if you've got multiple major versions for the same version of core, you get a radio to select which version is recommended.

Update status (both in D6 core and D5 contrib) already knows about all of this, it just hasn't been visible on d.o yet. So, previously, when you changed the "recommended version", update status would immediately warn users they should upgrade, which caused much confusion and hassle. Now, update status will only warn users to upgrade once you uncheck the "supported" checkbox. So, you can have both 5.x-2.* and 5.x-1.* supported, and 5.x-2.* recommended, and update status won't bother people still running 5.x-1.*. However, say you ship a 5.x-3.*, and decide to drop support for 5.x-1.*, you can uncheck the box and update status will tell them to upgrade.

Now, all it means when you mark a given major version "recommended" is a) it's displayed as such on the project nodes, b) update status says so in its status report, and c) it's the version that'll be shown in the project teaser in the project browsing pages.

Furthermore, recommended releases are now colored green on the project nodes and project browsing pages, whereas -dev snapshots are always marked as red (to warn people not to download them for real sites).

I also fixed a caching bug where sometimes the release tables would have "edit" links in them which most users would get permission denied on, while other tables wouldn't have edit links for users who could use them.

Finally, I fixed a wonky bug that would require visiting and saving the "releases" subtab of the edit tab on your project node whenever you added a new release for a whole new version of core.

Enjoy, -Derek (dww)

p.s. Thanks to Tao (starbow) for some of the cool jQuery goodness on that new edit/releases UI.

p.p.s. Thanks to Chad (hunmonk) and Adam (aclight) for reviewing and testing this stuff.

[1] http://drupal.org/node/176776 [2] http://drupal.org/node/203313

-- Regards Steven Jones

check theming dr6 handbook how to define new region... Mac On Thu, Mar 6, 2008 at 10:56 AM, Surya Namala <surya.namala@valuelabs.net> wrote:

Hi, Any body help me out on below issue. I have successfully installed Drupal 6.1 in my local environment but I am not able to create own regions.Please help me out.

Regards, Surya

----- Original Message ----- From: "Steven Jones" <darthsteven@gmail.com> To: <development@drupal.org> Sent: Thursday, March 06, 2008 3:12 PM Subject: Re: [development] New functionality on project nodes installed ond.o

...

Wow, that's very fab.

Just a minor nitpick: The images on the RHS of the table for dev snapshots have an alt and title attribute of 'error', but there isn't any error going on. Maybe a text like:' Snapshots are for development only, NOT for production servers' or somesuch.

Otherwise great work.

On 06/03/2008, Derek Wright <drupal@dwwright.net> wrote:

...

If you own any project nodes on d.o please read this...

I just finished up a patch[1] that was holding up a string of improvements to project nodes. The most important new functionality is that you now have more fine grained control over what releases are displayed on your project nodes[2].

First of all, for each version of core, you now have separate controls for every major version, where you can specify if that core/ major combination is supported, and if you want a dev snapshot displayed for it or not. Then, if you've got multiple major versions for the same version of core, you get a radio to select which version is recommended.

Update status (both in D6 core and D5 contrib) already knows about all of this, it just hasn't been visible on d.o yet. So, previously, when you changed the "recommended version", update status would immediately warn users they should upgrade, which caused much confusion and hassle. Now, update status will only warn users to upgrade once you uncheck the "supported" checkbox. So, you can have both 5.x-2.* and 5.x-1.* supported, and 5.x-2.* recommended, and update status won't bother people still running 5.x-1.*. However, say you ship a 5.x-3.*, and decide to drop support for 5.x-1.*, you can uncheck the box and update status will tell them to upgrade.

Now, all it means when you mark a given major version "recommended" is a) it's displayed as such on the project nodes, b) update status says so in its status report, and c) it's the version that'll be shown in the project teaser in the project browsing pages.

Furthermore, recommended releases are now colored green on the project nodes and project browsing pages, whereas -dev snapshots are always marked as red (to warn people not to download them for real sites).

I also fixed a caching bug where sometimes the release tables would have "edit" links in them which most users would get permission denied on, while other tables wouldn't have edit links for users who could use them.

Finally, I fixed a wonky bug that would require visiting and saving the "releases" subtab of the edit tab on your project node whenever you added a new release for a whole new version of core.

Enjoy, -Derek (dww)

p.s. Thanks to Tao (starbow) for some of the cool jQuery goodness on that new edit/releases UI.

p.p.s. Thanks to Chad (hunmonk) and Adam (aclight) for reviewing and testing this stuff.

[1] http://drupal.org/node/176776 [2] http://drupal.org/node/203313

-- Regards Steven Jones

-- - kindest regards Maciej Perlinski maciej.perlinski@meant4.com http://www.meant4.com

no problem On Thu, Mar 6, 2008 at 2:20 PM, Surya Namala <surya.namala@valuelabs.net> wrote:

Thnx Mac

----- Original Message ----- *From:* Maciej Perlinski <maciej.perlinski@gmail.com> *To:* development@drupal.org *Sent:* Thursday, March 06, 2008 5:27 PM *Subject:* Re: [development] Urgent Help

check theming dr6 handbook how to define new region...

Mac

On Thu, Mar 6, 2008 at 10:56 AM, Surya Namala <surya.namala@valuelabs.net> wrote:

...

Hi, Any body help me out on below issue. I have successfully installed Drupal 6.1 in my local environment but I am not able to create own regions.Please help me out.

Regards, Surya

----- Original Message ----- From: "Steven Jones" <darthsteven@gmail.com> To: <development@drupal.org> Sent: Thursday, March 06, 2008 3:12 PM Subject: Re: [development] New functionality on project nodes installed ond.o

...

Wow, that's very fab.

Just a minor nitpick: The images on the RHS of the table for dev snapshots have an alt and title attribute of 'error', but there isn't any error going on. Maybe a text like:' Snapshots are for development only, NOT for production servers' or somesuch.

Otherwise great work.

On 06/03/2008, Derek Wright <drupal@dwwright.net> wrote:

...

If you own any project nodes on d.o please read this...

I just finished up a patch[1] that was holding up a string of improvements to project nodes. The most important new functionality is that you now have more fine grained control over what releases are displayed on your project nodes[2].

First of all, for each version of core, you now have separate controls for every major version, where you can specify if that core/ major combination is supported, and if you want a dev snapshot displayed for it or not. Then, if you've got multiple major versions for the same version of core, you get a radio to select which version is recommended.

Update status (both in D6 core and D5 contrib) already knows about all of this, it just hasn't been visible on d.o yet. So, previously, when you changed the "recommended version", update status would immediately warn users they should upgrade, which caused much confusion and hassle. Now, update status will only warn users to upgrade once you uncheck the "supported" checkbox. So, you can have both 5.x-2.* and 5.x-1.* supported, and 5.x-2.* recommended, and update status won't bother people still running 5.x-1.*. However, say you ship a 5.x-3.*, and decide to drop support for 5.x-1.*, you can uncheck the box and update status will tell them to upgrade.

Now, all it means when you mark a given major version "recommended" is a) it's displayed as such on the project nodes, b) update status says so in its status report, and c) it's the version that'll be shown in the project teaser in the project browsing pages.

Furthermore, recommended releases are now colored green on the project nodes and project browsing pages, whereas -dev snapshots are always marked as red (to warn people not to download them for real sites).

I also fixed a caching bug where sometimes the release tables would have "edit" links in them which most users would get permission denied on, while other tables wouldn't have edit links for users who could use them.

Finally, I fixed a wonky bug that would require visiting and saving the "releases" subtab of the edit tab on your project node whenever you added a new release for a whole new version of core.

Enjoy, -Derek (dww)

p.s. Thanks to Tao (starbow) for some of the cool jQuery goodness on that new edit/releases UI.

p.p.s. Thanks to Chad (hunmonk) and Adam (aclight) for reviewing and testing this stuff.

[1] http://drupal.org/node/176776 [2] http://drupal.org/node/203313

-- Regards Steven Jones

-- - kindest regards Maciej Perlinski maciej.perlinski@meant4.com http://www.meant4.com

-- - kindest regards Maciej Perlinski maciej.perlinski@meant4.com http://www.meant4.com

On Mar 6, 2008, at 4:42 AM, Steven Jones wrote:

The images on the RHS of the table for dev snapshots have an alt and title attribute of 'error', but there isn't any error going on. Maybe a text like:' Snapshots are for development only, NOT for production servers' or somesuch.

Good point. On Mar 6, 2008, at 8:04 AM, Nancy Wichmann wrote:

The only part I'm not crazy about is marking -dev's in red ("to warn people not to download them for real sites"). With the number of modules that never produce official releases, I think this is going to cause a bit of heartburn and confusion in the community.

People with modules that never provide official releases cause more than a bit of heartburn and confusion in the community. This change is one of many that attempts to further penalize and (to borrow the hot-button phrase of an earlier thread) marginalize projects that never create official releases.

But we'll see how it goes. I'm assuming this is a CSS thing, so it will be easy to change if it does.

Indeed. It's all just CSS, so we can certainly change the look whenever/however we want. -Derek (dww)

On Mar 6, 2008, at 11:14 AM, Derek Wright wrote:

Please bear with me as I sort this out.

Everything should be happy now. Feel free to twiddle your bits as needed. Sorry for the slightly bumpy ride (and the extra noise on this list). -Derek (dww) p.s. sorry, this should have gone out hours ago, but due to the crappy network at the drupalcon, it's still sitting here unsent when i opened up my computer back where i'm staying. apologies for the delay.

what about modules that have dependency on other modules. how can we specify which parent module version my module supports? On 3/6/08, Nancy Wichmann <nan_wich@bellsouth.net> wrote:

...

People with modules that never provide official releases cause more than a bit of heartburn and confusion in the community. This change is one of many that attempts to further penalize and

...

marginalize projects that never create official releases.

I understand this, and largely agree with it. For the most part, I use -dev as sort of an "alpha" state that doesn't remove the old official version.

Having now looked at it, I would really like to see the checkmark and red X taken off. I think the red X really makes more statement than should be made here. The colors should be sufficient.

Nancy E. Wichmann, PMP

-- Oleg Terenchuk Web Manager / Developer Phone: 917 - 306 - 5653

On 3/6/08, Derek Wright <drupal@dwwright.net> wrote:

On Mar 6, 2008, at 11:38 AM, Oleg Terenchuk wrote:

...

what about modules that have dependency on other modules. how can we specify which parent module version my module supports?

In the body of your project node and in your release notes. Drupal has no support for version-specific dependencies, so you need to communicate these via the text channels of communication, not automagically.

-Derek (dww)

it was possible to do the same thing for drupal core support, and yet it was impleneted to be an automatic thing in the project module on d.o what stops from having modules be able to specify module dependency version based on what dependency they specify in the .info file ?

Can you please elaborate on this 'core version' dependency? To define a version dependency would be nice to have but the info file contains module dependencies and not project dependencies. Ie 'my_project' depends on module 'cclink (>=1.3)' provided by 'workflow_ng' The expression (>=1.3) can become quite complex. See http://www.debian.org/doc/debian-policy/ch-relationships.html as an appetiser :-) Cheers On Fri, 2008-03-07 at 00:10 -0500, Oleg Terenchuk wrote:

On 3/6/08, Derek Wright <drupal@dwwright.net> wrote:

On Mar 6, 2008, at 11:38 AM, Oleg Terenchuk wrote:

> what about modules that have dependency on other modules. how can > we specify which parent module version my module supports?

In the body of your project node and in your release notes. Drupal has no support for version-specific dependencies, so you need to communicate these via the text channels of communication, not automagically.

-Derek (dww)

it was possible to do the same thing for drupal core support, and yet it was impleneted to be an automatic thing in the project module on d.o

what stops from having modules be able to specify module dependency version based on what dependency they specify in the .info file ?

-- Clemens Tolboom build2be KvK NL020994130000 info@build2be.nl http://build2be.nl +31(0)6 10 27 96 95

Wuh, that was badly worded. So the only thing stops us is that there are people who think this is easy and they have the time, but they don't do it. So if you think this is the simplest and most important thing which should just happen, take the helm! Gabor On Sat, Mar 8, 2008 at 6:00 AM, Gábor Hojtsy <gabor@hojtsy.hu> wrote:

On Fri, Mar 7, 2008 at 6:10 AM, Oleg Terenchuk <litwol@gmail.com> wrote:

...

what stops from having modules be able to specify module dependency version based on what dependency they specify in the .info file ?

The only thing stops us is people like you who see this as easy and have the time to sit down and implement version support for dependencies and get that into Drupal core itself.

Gabor

On Mar 7, 2008, at 9:07 PM, Oleg Terenchuk wrote:

difficulty when you have a project with many modules but not every module supports every version

While version-specific dependencies are actually hard (in spite of Gabor's message that the only problem is that the people who think this is easy don't do it), there is a possible solution that is relatively straight-forward. Install profiles should be packaged up with everything they depend on into a single tarball. This is a much more simple problem to solve than functionality in core (and on d.o) to handle version-specific dependencies in general. Every profile just needs a file that lists the exact versions of the modules that should be packaged up with it. Even if people aren't going to run the profile to install a new site, they could still use the tarball as a collection of the right versions of a bunch of modules that depend on each other. Not only is this a partial solution to the version dependency problem, it'd be a massive usability win for install profiles. I even started a bunch of discussions on g.d.o about exactly how this will work, and I'm planning to start a fund-raising campaign to raise sponsorship to implement it all. My goal is to have this working on d.o within a month or two, but I can't yet commit to a date. Cheers, -Derek (dww)

The lesson here is that those saying "it is the easiest to do, why don't you do it" or "what stops you from doing that" as you used are easily jumped on. Although people love those asking "what is the issue URL" or "how can I help" :) Even if your approach is fine, the wording is important :) Gabor On Sat, Mar 8, 2008 at 6:07 AM, Oleg Terenchuk <litwol@gmail.com> wrote:

Okey i dont understand how i became the scape goat for this. i just delivered a message from ubercart BOF where people discussed difficulty when you have a project with many modules but not every module supports every version etc... so i'd appreciate you stop being so aggresive defensive on the issue.

On 3/8/08, Gábor Hojtsy <gabor@hojtsy.hu> wrote:

...

On Fri, Mar 7, 2008 at 6:10 AM, Oleg Terenchuk <litwol@gmail.com> wrote:

...

what stops from having modules be able to specify module dependency version based on what dependency they specify in the .info file ?

The only thing stops us is people like you who see this as easy and have the time to sit down and implement version support for dependencies and get that into Drupal core itself.

Gabor

-- Oleg Terenchuk Web Manager / Developer Phone: 917 - 306 - 5653

Thanks for the update. Looks really cool to add and retract versions. Cheers -- Clemens Tolboom