Stale package items in -dev snapshot releases for profiles

@Magnify: The link you reported doesn't take to any files.

When you attach a file to an issue report comment, the URL of the attached file always start with http://drupal.org/files/issues/.

I see there is a packaging component of the infrastructure queue so trying this issue there.

I've just taken over this and updated the core version to 6.16 in the drupal-org.make file. However, now THREE core versions are listed on the node release page - http://drupal.org/node/720948.

Please could someone advise whether this is something I can avoid!

http://drupal.org/node/642116#faq

@hunmonk, thanks for the reply.

But nowhere in the linked page does it explain that the release notes will say that there are multiple versions of Drupal core within a package. That's a bit of a WTF, and isn't true because the download only contains one version of core.

Having looked around a bit, it does seem that each profile that packages code does this on the dev release, so at least I haven't made a mistake in the .make file.

Where is the best place to post this as a bug? (If not already listed?)

But nowhere in the linked page does it explain that the release notes will say that there are multiple versions of Drupal core within a package

huh? there aren't. only one of the produced packages contains drupal core. the 'main' package contains core (and is the one used in the download links on the project page), and the two other packages are built for developers or others with special needs.

it's the project maintainer's responsibility to produce the release notes on a release node.

at this point, i'm confused as to what you're reporting as a problem.

I get the difference between the 3 packages, and I'm talking about the default package with core.

But - please see http://drupal.org/node/720948

Underneath "In this package", it has the Drupal project listed three times. With versions 6.14, 6.15, 6.16.

I think it should just say 6.16, as that is the code in the package.

ah, i see now. yes, that's a bug. :)

it's an issue with the way we're handling the insertion of package items into the {project_package_local_release_item} table. the code logic doesn't take into account that package items can change in -dev snapshots -- items are only ever inserted into that table. therefore, if a new release is included in a .make file, both it and the old release will be listed in the package -- not good.

attached patch adds a simple check to see if the built package is a -dev snapshot, and if so, it removes the existing package item list from {project_package_local_release_item} prior to the updated list being inserted.

tested this patch locally, and it works fine in both the tag and branch release node case. once it gets committed and deployed to drupal.org, the display problem on the -dev release nodes will be corrected the next time the packages for the project are built (for -dev snapshots, this is about 6-12 hours after the last commit to the end of the branch in question)

Phew, glad its not just me being mental!

Thanks to hunmonk for the work on this.

That patch looks fine to me. I guess it's a performance optimization to do the check for a -dev release to avoid the DELETE query for official releases from tags, although releases happen relatively infrequently so I almost think it makes more sense to just always clear out any existing entries before inserting. I'm happy either way.

However, is there a plan to correct all the existing -dev releases that have this problem? Don't we need some queries to repair the stale data? Wouldn't that be better as a DB update in this patch, than to just do it all manually on the live DB?

Thanks!
-Derek

from #11:

the display problem on the -dev release nodes will be corrected the next time the packages for the project are built (for -dev snapshots, this is about 6-12 hours after the last commit to the end of the branch in question)

is it really worth more coding time to write and test a database upgrade given that? i sure don't think so...

Oh, sorry I missed that. If it's self-correcting, great. Since you say it's tested and working, ship it! ;) Perhaps a final run on d6.p.d.o for safe measure would be nice before you deploy on d.o itself -- I certainly don't have time right now to do any testing myself...

Thanks!
-Derek

committed the patch in #11 to HEAD. setting back to active for drupal.org deployment.

Hi hunmonk / dww,

Any idea when this might be deployed on d.o.?

Thanks.

deployed a few days ago, forgot to update this issue.