Automatically create a LATEST tag

This is a cool idea.

Some questions, just to complicate it =)
Do we want to do 5-LATEST and 5-STABLE at the same time?

Actually that's really it. 5-LATEST would be all checkins; 5-STABLE would be the last release and only include whatever major branch the admin selected for the prdv table.

This seems like a good idea to me.

I usually want to have my modules updated to the latest stable release. It takes significant time to run down each module in use on each site I admin to find out what the latest version is, and fetch it.

If we can wait until Derek (dww) returns at the end of February, and he gives it his blessing, that would be ideal. But it shouldn't be too difficult to implement. just need to be careful with the edge cases.

I agree that we need a DRUPAL-5-STABLE, which is the latest tag the module maintainer created a release for, and hence consider stable.

As for 5-LATEST, this to me is the same as just DRUPAL-5, which is the latest commits to that branch.

Not quite. DRUPAL-5-LATEST might actually be in the DRUPAL-5--2 branch, which is one of the more poignant issues here.

would love this. i maintain my phpmyadmin with such a tag. see bottom of http://phpmyadmin.svn.sourceforge.net/viewvc/phpmyadmin/tags/

+1 - but shouldn't the intuitive tag for the branch DRUPAL-5 that is stable just be named DRUPAL-5 ?

for latest can'T I just to a CO DRUPAL-5 and get the (headlike) latest revision of that branch?

Christoph: http://drupal.org/node/116131#comment-191576

Oh, Chris, it's worth noting that hopefully soon we'll have the code in to make sites be able to ask Drupal if their modules are up to date; so keeping your site up to date should be easier.

:-)

i'm not thrilled about this proposal, though i'm not yet going to mark it "won't fix".

1. doing this would require giving some automated task write access to add/move tags anywhere in the contrib repo. that scares me both b/c of security, and b/c of potential error.
2. constantly deleting/adding/moving these tags around would generate a lot of noise in the RSS feed and email lists for cvs activity (unless we went further out of our way to filter these special cases out).
3. i'm not convinced that "cvs update -r D5-LATEST" is the best way to keep your site updated. even if you had this tag, you still wouldn't know what versions of each module you're using. update_status.module couldn't tell you you're out of date, your module page still wouldn't have any useful version info, etc, etc.

   i think a vastly better approach, even for people using CVS, is what i outline here:
   http://drupal.org/node/124661#comment-208348
   http://drupal.org/node/124661#comment-211008

>even if you had this tag, you still wouldn't know what versions of each module you're using.

DWW - I couldn't care less about exact drupal-5-x-y-z branch when updating the modules of my 20+ drupal sites

in fact, if somethings broken in a released module, it's a problem per se,
not just mine

I would use the DRUPAL-5-LATEST tag to update sites AND trust the contributors.
well, If they release crappy code, it's not any better than me not updating to the proper versions by hand
but IF their release is fine, so am I

I couldn't care less about exact drupal-5-x-y-z branch when updating the modules of my 20+ drupal sites

ok, but what i mean is there's no way you *could* know. and 99% of the time, you don't care. but when there's a bug that you need to report, you need to know what code you're running. having real version numbers on your modules page would be much easier faster for you and the module maintainer than CVS $Id$ tags, or worse "i don't know what version it is, i'm just using DRUPAL-5-LATEST, which i checked out yesterday".

please read the comments i pointed to above. the solution i outline there is even less work for you than having a DRUPAL-5-LATEST tag, since it would still work with the update_status.module (slated for inclusion in core in 6.x), so, you'd get pinged when you need to upgrade, instead of having to poll. yet, you'd still be able to deploy/upgrade directly with a CVS checkout (which, i agree, is quite handy, and how i manage all my sites).

given that i'd much rather put whatever effort i can spare on this topic into http://drupal.org/node/124661, not this automatically-moving tags stuff, i'm marking this "won't fix", since i have no intention of making this work. the other solution is better for everyone.

I am with Chris Cemper on this. The convenience of one command update from the repository is lost.

We can at least trust the maintainer of the module to say what is stable and what is not.

Again, this is just an alias. Think of it as a retagging every time an official release is done.

The maintainer can still mess things up, but this is true today, and was true before as well before the new release system.

Nothing beats one command checkout, and one command update. Please don't write this off.

you clearly didn't read the other issue. what i'm advocating in there is a 1-command update, too, it's just a different command...

that said, if you're stuck thinking this is better, and are unwilling to read the other issue, feel free to move this from "won't fix" to "patch (code needs review)" if you supply a patch. all the code you'd have to touch is in our contrib repo, there's nothing secret on d.o that's not checked in. but, i'm just saying, i'm not going to do this work.

Yes, I read it before. It is a step in the right direction, and covers certain scenarios.

With the current "checkout directly from the repository" model, one checks out the entire branch (e.g. DRUPAL-5) of contrib not just the module she uses. Then every now and then, she runs a cvs -q update -dP and it is done. New modules that are branched for that tag will appear automatically.

The "use LATEST as alias to latest release tag" just continues this direction and ease of use.

If your solution takes an argument of a branch tag (e.g. DRUPAL-5) and then trolls into the db remotely and determines what exact DRUPAL-5--x-y for each module, then that is fine. However, consider the load on the database for doing this, as well as opening an XML RPC (potential entry point). If we use cvs directly we avoid all these problems (no load on the db, no new potential holes).

Cleaning up old issues. Argued in #124661-15: provide CLI tool for updating a site from CVS based on update_status data that the need case was solved by http://drupal.org/project/drush
Tentatively marking as fixed.