Jim Riggs wrote:
The latest release date is based on when the branch was created, not when something was last committed.
I understand that. That's the problem. I want the current version of the module to be what people get when they click on the link that says "download latest release." Right now they're getting an old version. How do I fix that? --Sheldon
On 5 Apr, 2005, at 23:27, Sheldon Rampton wrote:
Jim Riggs wrote:
The latest release date is based on when the branch was created, not when something was last committed.
I understand that. That's the problem. I want the current version of the module to be what people get when they click on the link that says "download latest release." Right now they're getting an old version. How do I fix that?
I think you're misunderstanding the process. It is confusing, I must admit, so let's do it as an example. You may understand everything other than the packaging part, but others may find the whole example useful. (People with more knowledge of the inner workings of the system, feel free to correct me where I am wrong.) * I create and commit a new module "foo" (contributions/modules/foo). * This version is for Drupal 4.5, so I branch for 4.5: cvs tag -b DRUPAL-4-5 * At this point, I have a DRUPAL-4-5 branch and HEAD which are the same. * The Drupal packaging script (that automatically creates the .tar.gz of every project) runs every 6 (or 12?) hours. It crawls the entire contributions repository. For every project with files in HEAD, it creates a tarball that is labeled as the "cvs" version (foo- cvs.tar.gz). For every project that has a Drupal branch (i.e. DRUPAL-4-x), it creates a tarball for each version (foo-4.5.0.tar.gz). My understanding is that /all/ projects are packaged every time, so the tarball always contains the latest files; HOWEVER, the project page displays the date the version was first encountered as the "latest release" date. So if I created a branch on January 1 and committed new files yesterday, the date will still show Jan 1, but the tarball will include my changes from yesterday. I don't need to do any branching or tagging again. I only need to branch once. * Now I make some changes to HEAD to make it compatible with 4.6 and commit: cvs ci -m 'updated for Drupal 4.6' * The DRUPAL-4-5 branch of the module is for Drupal 4.5, and HEAD is now 4.6-compatible, so I can branch HEAD again for 4.6: cvs tag -b DRUPAL-4-6 * When the packager runs again, it will now pick up the 4.6 version and mark it as the latest release. There will now be three versions: foo-4.6.0.tar.gz with the latest files from DRUPAL-4-6, foo-4.5.0.tar.gz with the latest files from DRUPAL-4-5, and foo- cvs.tar.gz with the latest files from HEAD. In summary: The "latest release" date is not the date of the most recent change/commit. It is the date the version was first encountered by the project module. And, when a user downloads a tarball from drupal.org, he is always getting the latest CVS files for that particular version/branch (except, perhaps, for the 6 hour delay between runs). Now I am not saying this is the best system. There are lots of things I would like to see change in the entire versioning/packaging system, but this is how it is now. It /is/ confusing, so I understand what you were trying to do, but I don't think there is a way that you can get that latest release date to change. Hopefully this helps you to understand how things are working even if you don't understand why they are working that way. ;-) - Jim
Jim Riggs wrote:
* The Drupal packaging script (that automatically creates the .tar.gz of every project) runs every 6 (or 12?) hours. It crawls the entire contributions repository. For every project with files in HEAD, it creates a tarball that is labeled as the "cvs" version (foo- cvs.tar.gz). For every project that has a Drupal branch (i.e. DRUPAL-4-x), it creates a tarball for each version (foo-4.5.0.tar.gz). My understanding is that /all/ projects are packaged every time, so the tarball always contains the latest files; HOWEVER, the project page displays the date the version was first encountered as the "latest release" date. So if I created a branch on January 1 and committed new files yesterday, the date will still show Jan 1, but the tarball will include my changes from yesterday. I don't need to do any branching or tagging again. I only need to branch once.
Thanks for the complete description. It helped clarify a couple things for me. If it is not precisely correct, hopefully someone will provide corrections. One small correction I know about: it appears, at least emperically, that the packaging script only looks at some small subset of valid Drupa branches. That is, it appears to be building packages only for HEAD, DRUPAL-4-5 and DRUPAL-4-6 right now. I branched the ezmlm module for DRUPAL-4-4 only just recently (Allie and I updated it to 4.5 and 4.6, but it had been updated but NOT branched for 4.4 by someone else, so before committing our changes, I branched it for 4.4). But the 4.4 package has never been built. -- Chris Johnson
The latest release date is based on when the branch was created, not when something was last committed.
I understand that. That's the problem. I want the current version of the module to be what people get when they click on the link that says "download latest release." Right now they're getting an old version. How do I fix that?
If you already branched your module for 4.5, the best you can do is to do your changes in the 4.5 and in the HEAD branch, if you think your changes should go to the head branch too. The type of cvs commit messages you see indicate this type of workflow: ---------------------------------------------------------------------- HEAD commit message: - updated foo to be correct DRUPAL-4-5 commit message - updated foo to be correct (backported from HEAD) ---------------------------------------------------------------------- If you retag your module (ie. move your tag around), it will be harder to check out the changes you made to that branch, since the branch starting point will be moved, and we will not be able to see the changes you made to that branch. Check my january 7 commits here: http://drupal.org/project/cvs/9034 This way one can see how that README.txt evolved over time in the branches: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/commentrss/README... If I would have moved the release tag, or the branch starting point, noone would be able to tell that I changed something in the release. Goba
participants (4)
-
Chris Johnson -
Gabor Hojtsy -
Jim Riggs -
Sheldon Rampton