By dww on

The initial version of the New system for releasing Drupal contributions is now installed and functioning on http://scratch.drupal.org. All contribution maintainers are urged to take a look at the new system, try to use it, and make final suggestions for improvements before it goes live on drupal.org.

This is a site running on the main drupal.org infrastructure, with a copy of the drupal.org database from 2006-11-07. Everyone will be able to log in directly with their drupal.org username and password (no need for the "user@drupal.org" trick).

UPDATE 2006-11-03: The scratch database and cvs repository were wiped completely clean with the live data from drupal.org, and the latest version of all the release system code was installed. This is effectively the "release candidate 1" of the new release system. If you created your own tags and release nodes with the initial (beta) install on scratch.drupal.org, those are now gone, and you should try the new system out again.

UPDATE 2006-11-05: The configuration file for the CVS access control scripts was out of date on scratch.drupal.org. This has now been fixed, so a few of the usability/idiot-proofing features are now working properly.

UPDATE 2006-11-07: The database and cvs repository were wiped completely clean (again) to re-convert all the old releases into new nodes now that #90538 has been fixed and committed. Any test tags, branches or release nodes you might have added are gone, so you'll have to start over from scratch.


Using the scratch CVS Repository


In addition, there is now a scratch copy of the CVS repositories. This is essential for testing, since all releases in the new system are based on CVS tags and branches. The new scratch CVS repository is where you will be able to create the new kinds of tags for releases and see them on scratch.drupal.org. This repository is only for testing the new release system -- do NOT put code you care about into it, since it will all be deleted when the system goes live.

To make sure you are using the scratch CVS repository, you must change your CVSROOT environment variable or use the -d option to all of your cvs commands. The new root should be:

CVSROOT = :pserver:[user]@cvs.drupal.org:/scratch/cvs/drupal-contrib

where [user] is replaced with your regular drupal.org CVS username. So, the first step is to login to the scratch repository, like so:

cvs -d:pserver:[user]@cvs.drupal.org:/scratch/cvs/drupal-contrib login

Once you have accomplished that, you can now checkout a copy of your contributed module, theme or translation:

cvs -d:pserver:[user]@cvs.drupal.org:/scratch/cvs/drupal-contrib co contributions/modules/[your_module]
or
cvs -d:pserver:[user]@cvs.drupal.org:/scratch/cvs/drupal-contrib co contributions/themes/[your_theme]

Whatever directory you check this out into will remember it's from the scratch repository, so further cvs commands in that directory will no longer need the -d:pserver... option.


Version numbers in the new system


Contributed modules will now have a more elaborate version number, to indicate the version of core they're compatible with, whether they're a stable or development release, and what specific "patch level" of the code it represents. The new version strings will have the form:

[CoreCompatibility]-Major.PatchLevel[-ExtraStuff]

The [CoreCompatibility] part is required, and will be something like "4.7.x", or "5.x". Major is the major revision number, i.e. what branch of the code this release is coming from. The default stable branch for a given release of core (DRUPAL-4-7) will be the 1 major version (UPDATE: this post originally wrote that the initial version from the default stable branch would be the 0 major version... after outcry from the community, this is now changed in the code -- the new copy just isn't installed on scratch.drupal.org yet). Additional branches will be 2, 3..., and will be for whatever the maintainer of the project sees fit. It's up to the project maintainer to document on their project node and in their releases how they're using their own branches. The PatchLevel is for a specific release along the specified branch. The [-ExtraStuff] is optional, for specifiying things like "-beta1" (first beta release) or "-dev" (a development snapshot from the end of a CVS branch, as opposed to an official release from a CVS tag).

See http://scratch.drupal.org/handbook/version-info#contrib for a draft of the new handbook documentation about contrib version numbers...


Creating release tags in the scratch CVS repository


I'll be generating updated handbook pages explaining all of the CVS tagging conventions in the near future, with detailed examples and explainations. In the meantime, this summary will have to do.

Official stable releases:

If you want to add the 4.7.x-1.0 release, (the initial, stable release compatible with Drupal 4.7.x), you need to create a tag on the DRUPAL-4-7 branch of you code called "DRUPAL-4-7--1-0". For example, once you have checked out your local copy from the scratch repository as described above, you would do this:

cd contributions/modules/your_module
cvs update -r DRUPAL-4-7   # updates to the end of the DRUPAL-4-7 branch
cvs tag DRUPAL-4-7--1-0    # creates the release tag for the "4.7.x-1.0" release.

Branch for new development:

If you want to make a new branch off of your DRUPAL-4-7 branch for adding new features, you'd do this:

cd contributions/modules/your_module
cvs update -r DRUPAL-4-7   # updates to the end of the DRUPAL-4-7 branch
cvs tag -b DRUPAL-4-7--2   # creates the new branch

Official release off a development branch:

To make a real release off of this new branch, you'd do the following:

cd contributions/modules/your_module
cvs update -r DRUPAL-4-7--2   # updates to the end of the DRUPAL-4-7--2 branch
cvs commit your changes/new features   # for testing the new system, this is optional, of course...
cvs tag DRUPAL-4-7--2-0   # creates the new release tag, for the "4.7.x-2.0" release


Creating release nodes on scratch.drupal.org


Once you have created a release tag, and/or a new branch (e.g. for a development series for adding new features to code that's still compatibile with Drupal core 4.7.x), you have to create a new release node that points to your CVS tag or branch. First, you have to navigate to your project's node. Say you maintained the signup module (that's me):

http://scratch.drupal.org/project/signup

Since I maintain this project, I see a link "Add new release" under the "Releases" heading. Clicking on that will bring you to:

http://scratch.drupal.org/node/add/project_release/29351 (29351 is the nid of signup's project node).

For you to see the "Add new release" link, you'll have to look at a project you maintain (or have CVS access to).

This is a multi-page form that you fill out to create your release. On the first page, you select the CVS identifier you want to use from the list of available branches or tags that aren't yet associated with a release. If you're adding a release from the HEAD (the trunk of the repository), there's an intermediary page where you have to indicate what version of Drupal Core this release series is compatible with. The final page of the form is the main form to really add the node, now that the CVS identifier and other information has been fixed. The version number for the release is determined solely by the CVS identifier, so you can't change it on the final page.

Once you submit the release, it will initially be unpublished. Only once the packaging script runs to create a downloadable file will the release become published. The packaging script runs every 5 minutes to create releases based on CVS tags (official releases) and only every 12 hours to re-create tarballs from CVS branches (the development snapshots). If you add a new branch where you want development snapshots, it will therefore take as much as 12 hours before the release becomes published and visible in the issue queue, module browsing pages, etc.

UPDATE: 2006-11-05 Thanks to #93115 (now installed on scratch.drupal.org), as soon as you submit a release node, a message is printed to the screen informing you about these delays, how long you might have to wait to see the node published depending on if it is from a branch or a tag, etc.

You can also check out the article about the new release system written by Kjartan on his site (complete with some screenshots).


Background


Albert Einstein wisely said, “Make everything as simple as possible, but not simpler.” Unfortunately, Drupal development happens in a very complicated context, with rapidly changing versions of the core API, the interaction of different modules, the need for stable and development versions of many modules, and so on. Balancing the needs of a simple, usable system with something powerful enough to solve the problems we currently face has been a constant challenge.

So, you think I'm crazy, right? Like none of this makes any sense, it's way too complicated, blah blah blah. ;) Well, before you start an uninformed flame rant against me, I encourage you to read some of the discussions that led to this system:

Still think I don't know what I'm doing? ;) By all means, I'd love to hear your constructive suggestions for how this could be better and still provide all the functionality we need. Again: "as simple as possible, but no simpler" ...


Known issues: Critical before the system is deployed


Here's a list of all the known issues that are preventing the system from being deployed:


Known issues: Future work


Here's a list of all the issue's I've already submitted for future work -- things about the current system I'd like to improve, and issues other people have suggested. I don't consider any of these critical enough to further delay the initial deployment of the system, but they should all be fixed eventually. I'm keeping this list updated (and roughly in priority order, as i see it) so there's a central place to keep track of future work. Volunteers, anyone? ;)

Completed items:


Providing feedback


There are a few places you can provide feedback, bug reports, etc:

Thanks!
-Derek

Comments

msameer’s picture

msameer commented

I'm just asking some questions and probably the answer to all is yes. I'm just trying to understand!!

So. I assume that the major and patch level are version numbers for the module itself ?
and that CoreCompatibility is the drupal part ?

If I do cvs tag DRUPAL-4-7--foo It'll be compatible with all the 4.7 releases ? While if I do cvs tag DRUPAL-4-7-0-foo It'll be only for the 4.7.0 release ?

What if I want to create a branch DRUPAL-4-7--1 and tag the new release as DRUPAL-4-7--0-2 ? Is this going to work ?

Edit: I'm also trying to create a release for drupal 4.7.0
cvs tag DRUPAL-4-7-0-1
cvs tag DRUPAL-4-7-0-0
cvs tag DRUPAL-4-7-0--1
cvs tag DRUPAL-4-7-0--0

I even thought about creating a branch for 4.7.0 but I wasn't able to.

Tomi’s picture

Tomi commented

Should users that aren't logged in see the link "Add new release" on project pages? When they click it, they get "You are not allowed to create content." This link serves no purpose, so it should be deleted (or changed it to go to user/login).

Tomi’s picture

Tomi commented

I'm sorry, I didn't notice the part where you said that you are aware if this and it will be fixed later. My fault.

toddy’s picture

toddy commented

Hi,

thanks for your great work, I think it's quite easy to work with this system. Also thanks a lot for the scratch area to give it a try.

Two questions remain, however: Although I tried to read all of the nodes you cited in the "Background" section, I could not find the reasoning why the first release is called 4.7.x-0.0 instead of 4.7.x-1.0. Could you point me in the right direction?

The other thing is that I noticed that it's not possible to delete a release once it has been published, even after deleting the CVS tag of that release. What's the reasoning behind this decision?

Thanks,
Tobias

dww’s picture

dww
we/he/they
commented

re: 4.7.x-0.0 vs. 4.7.x-1.0:
the final details of the version strings are one of the only things i'm still not 100% happy with. here are the reasons (such as they are) for using 0.0 as the initial, default stable series for a given branch of core:

  1. at one point, we considered using an even==stable, odd=development version number scheme for core. it seemed horrifying to have 5.1.0 mean development in core, but 5.x-1.0 meaning stable in contrib. we didn't end up going that route, and now use 2-digit version numbers for core (http://drupal.org/node/86823) so this isn't much of a valid reason anymore. however, contrib still has the problem of stable vs. devel, and everyone's used to even==stable from the linux kernel, so it might still be worth keeping this convention...
  2. it's a little bit like what we have now -- the current "4.7.0" releases of contrib are all you get, the existing "stable" branch still compatible with 4.7.x. so, 4.7.x-0.0 stands in the tradition of "0 after the version of core is the default stable release".
  3. the corresponding CVS branch would be "DRUPAL-4-7". the 4.7.x-1.0 release would come off of a branch called "DRUPAL-4-7--1". in the "DRUPAL-4-7" case, there's nothing after the version of core, and 0 is often synonymous with nothing. ;) there's 0 extra junk after the core version, so it's version 4.7.x-0...
  4. computer people like to start counting from 0. ;)

as you can see, none of these are ultra-compelling reasons. i motivated this decision at the drupalcon talk i gave in brussels about the new release system (http://drupal.org/node/86694) and the people there seemed to be ok with it. however, if there's outcry from the community over this, and everyone thinks starting with 1.0 would be better, it wouldn't be hard to change this.

re: never deleting releases:
when you have an issue in the queue that's pointing to a release, we internally store the nid of that release. this is how things have always worked (though it used to be a release id, not a node id, but it's basically the same thing). so, if you were to delete a release, all the issues that were filed against that release would be pointing to an invalid release without a version number. plus, once you release something, it's out in the wild and there might be instances of it that exist on people's sites. there's no real turning back from a release -- once it's out, it's out. all you can do is make another one. ;) therefore, deleting a release node is just a bad idea, so it's prohibited. if you don't want a release to be available, you just unpublish the node and it disappears (though old issues pointing to that release still work). in fact, deleting a cvs tag or branch is also usually a bad idea, especially if a release node is pointing to it (http://drupal.org/node/90483).

hope that helps,
-derek

___________________
3281d Consulting

toddy’s picture

toddy commented

Hi,

the even==stable, odd=development version number scheme is certainly widely understood amongst developers and users. However, the Linux kernel has used this scheme for the minor version number, not the major version number (i.e. 2.0==stable, 2.1==dev, 2.2==stable etc.). For the contrib modules, I think that the first part of the version number would be considered the "major" version number, so starting at 1 would not imply a development version IMHO.

I can see the logic behind your answer #3, it's certainly true that starting at 0 is appropriate for a branch name of "DRUPAL-4-7". On the other hand, a module version number of 0.0 would imply to me a pre-alpha software at best, even more with the added "-dev". So the default release of the DRUPAL-4-7 branch would be called "4.7.x-0.0-dev", which does not seem like a ready-to-be-shipped module. Just my 2 cents. Well, you can always work around this with CVS tags.

Concerning the deletion of releases, I have to agree with you that this is generally a bad idea and should be prohibited. I was just playing around, knowing that the scratch area will be gone after the tests ... ;-)

Still, I'd like to remove a release from the listing of available releases, and it seems that there's no way to achieve this. You mentioned that I could simply unpublish the release node -- but how/where do I do this?

Regards,
Tobias

dww’s picture

dww
we/he/they
commented

personally, i consider the drupal core compatibilty the "major" version (what basic API compatibility it has), and then what's now "major" is more like the "minor" version (still within the same API, what set of features) and the "patch" is the patch. maybe that's how it should be used/documented/explained. then, even vs. odd for "minor" makes more sense. it really is the middle "digit" of the version number, it's just that the first "digit" is a little more complicated...

speaking of the first "digit", i'm not 100% convinced i like having the ".x" in there. it makes sense to me that it's a variable which takes the place of any patch-level version of core. so, a module ported to the "4.7.x" API should work just as well with 4.7.1 as with 4.7.3. however, i can agree that not all drupal users find version number algebra as easy as i do, and the .x could confuse. furthermore, as the recent security release of 4.7.4 shows, the API is not quite as fixed as we like. :( i still think in the rare special cases like the 4.7.4 or 4.6.10 release that slightly change the API, that should just be explained in the release notes for later releases of your modules off the 4.7.x series. the other thing i like about the '.x' is that it helps visually separate the core part from the contrib part of the version #. so 4.7.x-0.1 instead of 4.7-0.1. the 2nd one looks too much like 4.7.0.1 for my tastes, and that gets extra confusing with 4.7 vs 5 (i.e. 5-0.1). however, again, if there's outcry, and everyone wants to get rid of the '.x' from the core compatibility terms, we can do that.

in terms of the "-dev" releases -- that's the point: you shouldn't use them, if possible. one of the things the new system is trying to do is discourage people from using "moving target" code. if you're a responsible maintainer, you should make an official "4.7.x-0.0" release when you think your module is stable, and that should be the default download. the -dev releases (auto-regenerated from the end of a branch) are a pain in the ass. neither you nor your users know what code they're actually using. if it were up to me, i'd just remove these entirely, and force maintainers to tag official releases for any code they want available for download. if someone wants to help test the next release, they can get the code directly from CVS. ;) then again, we don't want to have any barriers in the way of people helping to test/develop contrib code, and CVS is a barrier for some people. but, that's the only reason we're making the -dev releases available. it isn't production-ready code, b/c it hasn't been released yet...

the medium term goal is to at least make these "releases" more and more obviously do-not-touch code, in a separate download table when looking at all releases for a project, etc, etc.

re: unpublishing your own bad releases, see http://drupal.org/node/90531. i forgot you need administer content permission to see that choice. since this is rare, for now, you can just email the infrastructure list and someone will take care of it for you. ;)

___________________
3281d Consulting

pwolanin’s picture

pwolanin commented

Was this forum topic publicized on the devel list? If so, I missed it.

Anyhow, I'd think that the 1st relase should be --1-x rather than --0-x. to me a 0.x series implies "not really ready for relase". I'm about to start playing with the scratch.drupal system, but it seems like there is nothing that prvents a developers from making the 1st release as --3-0 if they prefer, right?

---
Work: BioRAFT

pwolanin’s picture

pwolanin commented

so I just tried it:

http://scratch.drupal.org/project/node_clone

I was, indeed, able to make a release based on a DRUPAL-4-7--1-0 without using the --0-0 tag first. Would doing this cause problems? Can I confuse everyone by making a --0-0 release later. Yes, I know that it would be dumb to do so, but I'm just trying to get a sense of what level of idiot-proofness is built in.

What happens if I delete the tag or apply it to a different version of the files? I assume the release is already packaged and immutable?

Also, a minor bug of sorts- I made the new release the default right away. In the ~5 minutes between creating a the release and when it was packaged up, the download link on the main project page showed a link to a (non-existant?) file with a unix timestamp of zero (i.e. Jan 1, 1970).

Finally, your instructions above suggest making an additional branch for development of the next release. I don't see why this is necessary in a typical case (new features in a small module)? Is this more of a philosophical issue than a practical one? In this "typical" case should I just be using minor version numbers? Obviously in the rare case where I'm changing lots of features or the API and I exepct to be supporting users with minor updates of the previous release it would be useful to branch.

Thanks for making this new system happen!

---
Work: BioRAFT

dww’s picture

dww
we/he/they
commented

pwolanin, thanks for the careful testing and comments...

I'm just trying to get a sense of what level of idiot-proofness is built in.

very good question. i'd say the drupal code itself has a high level of idiot-proofness built in. the forms never allow regular users to input things they shouldn't be able to change when adding or editing releases. however, the major stupidity can (and will) happen trying to use CVS directly (making tags and branches) and that's an area that could certainly use more work and hardening before this all goes live. it's a totally separate part of the code, and it wasn't my primary focus, but i think it should be now.

re: deleting tags or trying to move them. i mention that in the list of known issues, about 1/2 way down:
http://drupal.org/node/90483 prevent deleting tags that have release nodes pointing to them

however, there are probably some other things we could attempt to prevent:

  1. enforce sequential release tags. e.g. if DRUPAL-4-7--1-1 exists, but not DRUPAL-4-7--1-2, prevent users from adding a DRUPAL-4-7--1-3 tag (or really, DRUPAL-4-7--1-N where N > 2). this is easy, since we have a {cvs_tags} table with all tags per project, and can easily find out the last real tag for any given release series... in general, i think this will catch a lot of stupid errors, and it seems like something we'll definitely want to enforce. see http://drupal.org/node/90968
  2. prevent users from adding release tags to the wrong branches. this would be great, but is in fact difficult or impossible to do in all cases, just b/c of the way cvs works and what info you have to work with when validating a tag. :( i'll continue to investigate if this is feasable, but i'm not optimistic at this point

thanks for the bug report on the bogus link for the default download. a version shouldn't show up in that list before it's been published, so you can't set something as the default version until it's been packaged and is publically available.

in terms of a new branch... i was only talking about adding a branch (e.g. the DRUPAL-4-7--2 branch, assuming we move to -1.x for the releases off DRUPAL-4-7) if you plan to add *new features* to the 4.7.x version of your module. we want to encourage responsible maintainers to do The Right Thing(tm). if they're adding new features, it's inherently unstable, and they shouldn't risk breaking the stable branch of their code. only bug-fixes should go in the default branch (e.g. DRUPAL-4-7), and if you want to add new functionality or reorganize the code, do it in a new branch (e.g. DRUPAL-4-7--2). if you just want to work on the next bug-fix-only release of your module, no reason for another branch, just do that directly in the DRUPAL-4-7 branch (just like you do already), and add a new release tag when you have a coherent set of changes you think are ready to be released. make sense?

of course, the decision to branch or not is ultimately up to the maintainer (we can't force them to be responsible). also, it really depends on the userbase of their module, how new it is, etc. if it's a small, relatively new module with almost no users, it's entirely reasonable to add new features to the default DRUPAL-4-7 branch (for example). however, as the module matures, and more sites rely on it, the maintainer should reconsider if, for example, in the 5.x world, if they want to switch to stable vs. devel branches...

___________________
3281d Consulting

pwolanin’s picture

pwolanin commented

In response to #1 above, I think that enforcing sequential numbering would be unnecessarily restrictive, but that there should be a check that each new tag/version is greater than the previous. E.G. if I want my FireFox module to go from version 1.0 to 1.5 to be suggestive of lots of bug fixes, etc., I think I'd want to be able to do that.

---
Work: BioRAFT

dww’s picture

dww
we/he/they
commented

everyone except me seems to prefer starting from 1.0 for the stable branch. so be it. ;)

this also has the minor side benefit of saving the 0.x releases for releases from HEAD. see http://drupal.org/node/58066#comment-104665 for more on this...

anyway, i'll make new versions of the d.o conversion script, and a few other parts of the code that have to change to deal with this change. stay tuned. i'll post another reply here once the version installed on scratch.d.o has been upgraded.

___________________
3281d Consulting

kkaefer’s picture

kkaefer commented

Cool! And by the way, it's not that complicted. Your explanations are straightforward.

The double-dash between the Drupal version identifier and the module version is a separator, right? Can "extrastuff" be used for code names?

dww’s picture

dww
we/he/they
commented

the double-dash separator is only used in the CVS tag and branch names, not in the version strings.

thankfully, it's impossible to use "extrastuff" for codenames. ;) if contrib maintainers *desperately* want code names, it's up to them to put the names in the description field of their releases, and i can't stop them. however, users caught attempting to put codenames into the "extra information" field will find their cvs accounts revoked. ;) (just kidding -- but it's a nice threat to brandish, even if i don't have the means to enforce it)...

___________________
3281d Consulting

bertboerland’s picture

bertboerland commented

something like this, shorter and easier :-) should make it to the homepage.

Are you feeling like redoing it this for a broader public or does anyone else feel like sharing this?

if so drop me a mail and I'll promote it if you didnt have the powers yourself

--
groets
bertb

--
groets
bert boerland

dww’s picture

dww
we/he/they
commented

i was going to wait for a frontpage story until the system is actually live. i figured that my email to the devel, infra and translations lists would generate enough traffic for this post, since it's really just contrib maintainers i'm interested in playing with the test site.

it'll definitely need to be front-page news once it goes live, since then everyone will see the new version numbers and have to know what's up. ;)

my basic plan was to take all the useful text out of this post and put it into the appropriate handbook pages (with additional info and edits), and then have a short summary of the new system for the frontpage story with links to all the right handbook pages for more info.

thanks,
-derek

___________________
3281d Consulting

dww’s picture

dww
we/he/they
commented

see http://drupal.org/node/92452 for a debate that's sprung up (mostly via email and IRC) about the meaning of the "main" branch for a specific version of core (e.g. what should the DRUPAL-5 branch mean in the new release system). please comment there. just posting here so people who've participated in this thread are more likely to see that other post. ;)

___________________
3281d Consulting

dww’s picture

dww
we/he/they
commented

this info is already updated in the body, but i'm adding a new comment so anyone following this post in their tracker will see that things are updated. ;)

now's your final chance to provide feedback on the system before it goes live.

thanks!
-derek

___________________
3281d Consulting

toddy’s picture

toddy commented

Hi Derek,

I've just tested the newly installed release system on scratch.d.o. Overall, I'm really happy with the workflow, thanks for your efforts. You might find my notes below useful.

  1. Handling of tags before they are associated with a release node: That went as expected, I was able to move a tag around, e.g. to recursively add a tag to my module's files and then fine-tune some selected files. I could also delete a tag. However, after I created a release based on the tag, none of these actions were possible anymore. Great. Also, the error message is quite clear.
  2. A new release is not appearing instantly. After I created a new release, it didn't show up in the list of releases, but only after the tarball has been created. Granted, this should be pretty clear, but it might be nice to mention in the handbook that some delays are to be expected. Moreover, it's not possible to select the newly created release as default release until the tarball arrived. Pretty sensible, but this should be mentioned in the handbook.
  3. Also an issue for the handbook: When specifying an extra part for the tag, e.g. DRUPAL-4-7--2-1-beta-1, the tag will be added to the repository. However, it doesn't show up as expected, because the extra part apparently does not allow to contain the hyphen. The tag would show up as DRUPAL-4-7--2-1-beta. To get the desired tag, one needs to use DRUPAL-4-7--2-1-beta1.
  4. Hm, don't know if this must be explicitely checked by your scripts, because I think it's rarely used, if ever. But still, I can create a tag DRUPAL-4-7--3-0 without having a corresponding branch DRUPAL-4-7--3. Thinking about it again, I do not think that this must be handled. Just an observation.
  5. Going crazy with development: I'm able to create a branch of DRUPAL-4-7--2876452, also the tag DRUPAL-4-7--782674-19862 works. Great, no limitation here. ;-)
  6. Oh, this one is important again. I've mentioned it already here, but the error is still there. I can create a DRUPAL-5 branch and a DRUPAL-5--1 branch. Both show up as module-5.x-1.0-dev. You need to disallow the branch name of *--1.

Well, that's all so far. Hope this helps.

Regards,
Tobias

dww’s picture

dww
we/he/they
commented

first, thanks for the good feedback...

now, my replies:

re #1: glad you like it. ;)

re #2: this is clearly explained in the last paragraph of the section on Creating release nodes on scratch.drupal.org. the only handbook pages that need to be written (cvs tags/branches and release nodes) will basically just be cut and paste from this forum post...

re #3: hrm, that's slightly unexpected behavior of some regexps for the drupal.org-specific customization. i'll definitely look into that, thanks! (btw, i'm not sure it's a good idea to allow "extra" in contrib tags, and only use the "-dev" on snapshots from branches (automatically) but that's another story).

re #4: see point #2 in my comment idiot-proofness needs more hardening ;) above.

re #5 and #6: whoops, the config file for the cvs access control scripts on scratch.d.o doesn't have the most recent/accurate configuration for what we'll be running on the real drupal.org. i'll work with natrak or killes to fix that ASAP. thanks for catching it!

-derek

___________________
3281d Consulting

dww’s picture

dww
we/he/they
commented

kjartan was around in IRC, so we just fixed the CVS access control scripts on s.d.o to have the most current configuation. #5 and #6 are now fixed. i'll look at #3 next...

___________________
3281d Consulting

dww’s picture

dww
we/he/they
commented

i just had a chance to look at your #3 (trying to specify a tag with extra like "DRUPAL-4-7--2-1-beta-1"). this is now fixed (see http://drupal.org/node/93301) and installed on scratch.drupal.org.

___________________
3281d Consulting