8

When I used drush to check for updates to my site, which has about 100 modules installed, I was informed that the dev versions of several versions of the modules had updates.

However, when I updated the new version, the only thing that was changed was the packaging information and datestamp.

For example, this is the git diff for the Prepopulate module dev version:

-; Information added by drupal.org packaging script on 2013-05-25
+; Information added by drupal.org packaging script on 2013-10-01
 version = "7.x-2.x-dev"
 core = "7.x"
 project = "prepopulate"
-datestamp = "1369450574"
+datestamp = "1380623732"

That's it-- no actual changes to the code. If this was just one module, I wouldn't think much of it. However, I had several modules like this-- the Role Expire module, Views PHP module, PHP Mailer module, i18nviews, and there may be more.

It's pretty frustrating for me to download each of these updates and do a diff, only to see that nothing has changed. I feel that I am really wasting my time. Are the maintainers doing this? Does this have anything to do with Drupalcon?

Improve this question
7
  • 2
    I'm afraid your title may be wrong here. You assume it's maintainers who did it. Are you 100% sure it's not something done by drupal.org packaging script? Possibly on actions like branch creation or other git repo access that shouldn't trigger the repackaging?
    – Mołot
    Commented Oct 4, 2013 at 7:20
  • I see-- that thought didn't enter my mind. If that's the case, then, and the repackaging shouldn't have been created anyway, I suppose there's no hope of easily being able to detect and ignore such updates.
    – Patrick Kenny
    Commented Oct 4, 2013 at 7:23
  • The Project module is responsible for managing the projects on drupal.org (not completely sure how the packaging works); Maybe you could look into it. The 7.x version of this module is unstable as you can see, so this could be a bug in the module, and should be reported to the issue queue.
    – AjitS
    Commented Oct 4, 2013 at 7:50
  • To anyone voting this off-topis: Community involvement and Site-building are on-topic, and I don't think that this really falls into "Issues about drupal.org" off topic category - after all it's about dealing with the way modules are packaged on the user's side. And possibly about developing own modules kept there on Drupal.org. Maybe it should go to meta to discuss that?
    – Mołot
    Commented Oct 4, 2013 at 8:20
  • 3
    This is a "developer as end-user" problem and thus on topic-- I try to keep my site up-to-date. But I don't want to deal with "updates" that are not real updates, so I want to understand why this is happening.
    – Patrick Kenny
    Commented Oct 4, 2013 at 8:22

1 Answer 1

Reset to default
6

Strange, I selected some modules at random and I see dev versions consistently packed 2013-Oct-01. I can't find any one with another date now.

Examples I've tested:

and many more.

Edit: Some of them, closer to the beginning of alphabet, was packaged one day earlier:

but operation big as this surely needed to take considerable time and it still looks like one long rebuild queue.

With so many unrelated projects repackaged at the same day, and without any correlation to their GIT log, it must be something on the Drupal.org side that triggered mass repackaging.

It's simply impossible that all maintainers decided to rebuild at the same day, plus as far as I remember only way to trigger for them rebuild is via GIT anyway.

GOT IT

https://drupal.org/node/2101175#comment-7919049

-dev releases are currently being rebuilt ... working alphabetically, and there are a lot of packages, so it will take a while. :)

So it was a manual rebuild triggered to fix an issue with infrastructure, not something planned as regular action.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.