So the idea is that people can continue to test patch functionality- and API-changes against a snapshot while HEAD continues to flux out. And when the patch looks RTBC, it's re-rolled one last time against HEAD. Fixing all the function conflicts, etc.

Also, people can begin porting very early. Then they can have a say on where the API needs to change. This currently needs a release cycle. That's not good. It's fairly impossible currently as there is nothing to hold on.

How often? I do not know. Daily or weekly or even biweekly... just something, please. Discussion already at


Anonymous’s picture

+1 from me. Nothing like chasing a moving target to reduce enthusiasm. Snapshots would give us a chance to build / test / digest the results before making the last build / test / digest against HEAD before posting a patch.

smk-ka’s picture

Sounds reasonable. I'd go for something like Eclipse's integration builds, which are irregularly built whenever a component (that would be the bigger core patches in Drupal lingo) reaches a stable state, contrary to automatically built nightlies. Full explanation here.

sun’s picture

Title: Provide us with core developer releases » Provide us with core developer snapshots

+1 for monthly or biweekly snapshots/builds, so I am finally able to work on better core integration for my modules. For example:

To work on proper WYSIWYG support and usability (design) in Drupal, I need to use the system for real. A snapshot including cutting-edge innovations wouldn't force me to chase HEAD, but allow me to improve core, patches, and the overall system between snapshots.

catch’s picture

So what this gives us is a downloadable tarball which contrib developers can port their modules to - one which is fixed at a certain point in time. This means that if one module depends on another, say token and pathauto - both can be ported to the 230908-snapshot and they'll work together, as opposed to trying to guess which revision of HEAD each one might possibly work with or not - which is what you'd have to do if anyone took this task on the current way tracking HEAD (which not many people do of course)

It also means that someone can port their module to the first snapshot, then when the next snapshot comes out, let's say a month later, they can easily review the changes they need to make in chunks - as opposed to every day or in a huge chunk at arbitrary and unknown points in time. This becomes even easier when your module has tests, since if you get a 100% pass rate for snapshot 1, then some tests fail in snapshot 2, that gives you some decent feedback about where the changes are before you even read the changelog or the upgrade docs. We'll also be able to catch regressions or shortcomings in the API much quicker since contrib implements hooks that aren't implemented in contrib, or does different stuff with them - this combined with testing gives us a lot more coverage, a lot earlier on.

Although the upgrade path from 6-7 is currently broken, with testing we're getting less and less situations where HEAD is completely broken - so it should be possible to put out at least somewhat workable snapshots for people to develop against.

And for those developing new features for core - say the help system patch, or aggregator - it'd be easier to allow people to test the functionality visually against a particular snapshot - for usability testing etc. etc - refining the patch as opposed to both refining the patch and chasing HEAD - then a final re-roll to get it in when it's ready.

In short, a very good idea :)

Gerhard Killesreiter’s picture

This depends on webchick and Dries input.

chx’s picture

The first sentence of the original post was webchick's summary of my ravings. She also said "Ok, I can see the advantage of that". I only need Dries' nod on this, everyone else I already rallied behind it either in the old post, on IRC or here.

webchick’s picture

Sorry, this is kind of rambly... I'm a little distracted atm. Can be summed up as "Huge +1."

I originally didn't really understand why this would be useful, but catch and chx spent a lot of time patiently explaining this to me in #drupal.

I would really like the ability to do this, because it would give us the following advantages:

  1. It makes it easier to write core patches that do huge, sweeping improvements and touch lots of stuff. Currently, trying to author such a patch requires doing double duty:
    1. Making sure the code is working properly, is the best solution, and is using clean, well-documented, and coding-standard-compliant code.
    2. Catching up with the billions of other, more minor changes that get committed along the way, since the above ends up taking such a long time to get right through constant re-rolls.

    In the run of a typical "epic" patch such as DBTNG, it needs to be re-rolled almost constantly (typically, at least daily), because we fixed a bug with one query there. Or we committed a patch with whitespace fixes over here. Etc. Lots of time is wasted keeping up with these changes that have nothing to do with the actual functionality of the patch. Reviewers sit down on a cloudy Saturday afternoon with a coffee and 2 hours to spend reviewing a patch, and that time ends up getting allocated on tinier patches because the epic one doesn't apply anymore. We lose out, and these patches take much longer to commit than they otherwise would.

    If we had snapshot releases, and it was clear to which release a patch applied to, reviewers would be guaranteed that a patch would always apply, and could focus instead on the stuff that actually matters.

  2. The ability for module developers to chase HEAD in a more gradual and less daunting way, which results in us identifying bugs and API shortcomings well before code freeze, when it's too late to change things.

    Currently, the 6.x => 7.x upgrade docs list 15 API changes, the biggest one being the DBTNG changes. Someone could port their module up to the 20080923 7.x snapshot, and release their own current 7.x and release probably in a few minutes. Next dev snapshot, we might have a couple more things they need to change. Next one a couple more. And so on. The next snapshot, developers are talking about changing 1 or 2 more things, which typically takes a few minutes, spread over several dozen snapshots. Inter-dependent contributed modules can both port to the next snapshot at the same time.

    Naturally, contrib authors would still be porting at their own risk prior to code freeze. But, if enough start, this allows us to catch API short-falls MUCH earlier. Currently, developers avoid starting to port before there's something stable to port to (alpha1, at earliest) and at that point there is nothing that can be done about API short-falls until the next version.

  3. The ability to commit patches that take a stab at improving UIs, and then do field usability tests on those changes well before we get to the point of alphas/betas, at which time it's too late to do any radical changes and revamped based on user feedback. We currently can't do that easily.

To some extent, the importance of this is based on the suckiness of CVS, because we don't have a way to grab all of the files at a certain point in time short of doing a checkout by date. While we could instruct developers to do cvs checkout -D "23 Sep 2008", that's really sucky to try and coordinate among developers of inter-dependent modules, and even suckier to try and get beta testers to do.

One thing I want to make clear though, we should not call these "alpha" releases, as I've seen proposed. Alpha release tell me, as an end user, that what I'm testing is what the finished product will look like, plus or minus a few bug fixes and features. Drupal 7, although it is relatively stable as HEAD goes, is no where near alpha state right now. So it's important we frame user expectations correctly. "Development snapshot" or "snapshot" or something that makes it clear that these are to facilitate *developers* getting their jobs done, and not to give a "sneak preview" of Drupal 7, is very important.

Also, it probably makes sense for contrib to be able to roll development snapshots as well, so they can provide "early evaluators" of modules with a static tag to test with rather than "Download the 7.x-1.x-dev release from Oct. 23" :P

dww’s picture

Title: Provide us with core developer snapshots » Provide us with core developer releases

Around here, "developer snapshot" currently implies the automatically regenerated tarballs from CVS branches that end in "-dev". That's not what you're talking about. You mean having the core maintainers periodically create a release tag like DRUPAL-7-0-DEVRELEASE1 (or something, we need to decide on the terminology for these and tag accordingly) that would be an official release tag which never changed.

For background, I suggested we do this almost exactly 2 years ago when I was arguing to change the core numbering scheme from 3 digits to 2. See the original post at [#85943] ;) I still think this is a good idea, for the various reasons I wrote then, and all the reasons people are saying now.

My only word of "wisdom" is we should think carefully about the terminology so that it's self-documenting and consistent with (at least not conflicting with) our existing terminology.

catch’s picture

dww: yes, that's exactly what we're after.


webchick’s picture

@dww: Good point. So yes, maybe a term like "integration build," which is what Eclipse uses, would be best. Basically, the scarier it sounds to end users, the better. ;) I tried searching around other projects to see what they call this and had trouble finding much...

litwol’s picture

Edit: removed by author. Original post was coincidental and by no means result or the cause of the current issue.

webchick’s picture

Talking in #drupal about this more with various folks... sounds like a tag (NOT a .tar.gz) would be the best solution. These are releases by developers, for developers. End users trying to work on anything with Drupal 7 in advance of alpha/beta without some guidance by an experienced Drupaler would be disastrous.

Which basically means (I think) all we need is a tag naming convention; no fancy release system stuff.

dww, any suggestions?

joegml’s picture

Unstable is what Debian has used for a long time, with just this in mind: scare off the newbies.

"Unstable," oh my that sounds, ... unstable, ... it'll crash my system, ... I certainly won't use that! ;-)

webchick’s picture

Unstable. :) I love it! :D

DRUPAL-7-20080923-UNSTABLE ?

litwol’s picture

DRUPAL-7-UNSTABLE--[MAJOR PATCH ABREVIATION THAT GOT IN] ? where the last part could stand for things like 'DBTNG', etc.

or if nothing major went in then fallback on date. its not very consistent. i am voting for descriptive names unless if we intend to keep a page with mapping between tag name and what it actually means.

Edit: perhaps DRUPAL-7-UNSTABLE--[#ISSUE ID] is a better idea. it has relevant information that ties it to a real issue ID that a curious developer can go and research to see what warranted a snapshot tag.

webchick’s picture

Hm. I see that getting messy real fast. Our tags list ends up like:


IMO this is what CHANGELOG.txt is for.

sdboyer’s picture

+1 to the whole freakin thing.

...if we go be date. Oh dear god PLEASE DON'T use some 'more descriptive' tag. Just because I love webchick to death doesn't mean I want her (or anyone else's) opinion about what was important enough to justify a new developer's release etched into the CVS tag itself. Imagine if hook_file and DBTNG had gotten committed within hours of each other. Do we use HOOK_FILE or DBTNG for the release tag? It's a moronically trivial question, but a question - like certain bike sheds we all know and love - that we're inviting get asked every time a new dev's release is tagged.

Worse still, it's uninviting and exclusive. At least up to the week before it got committed, I saw people unaware of what 'dbtng' referred to in IRC - developer people. Are they just not cool enough to make it to the developer's party?

Eclipse definitely does this right with their integration builds. Since I run the integrations/nightlies of PDT2, I'm constantly going out and fetching the proper versions of the other plugins it's dependent upon. In updating from I20080722 to I20080909, here's the versions of various plugins I had to go from/to:

eclipse-SDK-3.4 (the main Ganymede release, R-3.4-200806172000) -> eclipse-SDK-M20080903-2000
emf-runtime-2.4.0(the Ganymede concurrent release, R200806091234) -> emf-runtime-2.4.1 (R200808251517)
xsd-runtime-2.4.0 (the Ganymede concurrent release, R200806091234) -> xsd-runtime-2.4.1 (R200808251517)
GEF-3.4.0 ->
dltk-core-I-I200807181303-200807181303 -> dltk-core-I-I200809081043-200809081043
dtp_1.6.0 -> dtp-1.6.1RC1-200809020500
wtp-R-3.0-20080616152118a ->

Personally, all those release ids looked like a big bunch of jumbled crap to me until I started running Ganymede, but they are actually sensible once you know what you're looking at. Imagine, however, if they decided to label their integration builds on the basis of some important new change that was made:

eclipse-SDK-3.4-BEEBLEBROX -> eclipse-SDK-3.4-BROXLEBEEP
xsd-runtime (CHUCKNORRIS) -> xsd-runtime (RICKROLL)

Now, I'm sure ALL those tags really had great meaning for the people who made them. But, lest we forget, this change wouldn't really be about the people who MADE the tag. And also - even though the examples are silly and there are several major differences between Eclipse's concepts of integration build and what we're talking about here, the basic principle behind the comparison still holds: we're talking about choosing between a subjective tag with potentially varying meaning depending on who's reading it, and something objective like, um, the date. Seems like a no-brainer to me.

jredding’s picture

I really do like the Debian unstable vs. stable systems. Its extremely clear as to what it going on.
CHANGELOG.txt tells you what happens in between versions including all of the Drupal issue IDs.

So I'd +1
DRUPAL -- Version # -- Stable/unstable -- minor version (incrementing from 1)

sun’s picture

Top stop this bikeshed:

- CVS pre-commit hook was recently updated to allow only certain tags - dunno, whether this applies to core at all, but anyway...
- we might want to have Update (Status) support

So, potential options are:

- DRUPAL-7-0-SNAPSHOT-20080922
- DRUPAL-7-0-UNSTABLE-20080922

Keyword DEV would also be possible, but clash with development snapshots. Note, that having dates in tag names will clutter our auto-generated list of CVS tags (somewhere in the handbooks), so I'd recommend straight increasing numbers, also to be consistent with all other CVS tags.

My favorite name, suggested as a metaphor by litwol, has been rejected by webchick, but I wanted to note it anyway - DRUPAL-7-0-HEARTBEAT-3

Crell’s picture

File me +1 as well, with the caveat of a non-descriptive tag. Date works, or a sequence number. I think I somewhat prefer a date as it is self-documenting, but both would avoid the problem that sdboyer correctly points out above with more "descriptive" tags. DRUPAL-7-UNSTABLE-DBTNG-OMG-AT-LAST is not very useful to others rolling big patches. :-) Having a known quantity to work against would have made DBTNG much easier, though, especially when I was heavily leveraging simpletest at the same time that simpletest was under heavy development.

If we do this, it should be on some regular schedule; weekly, every other week, something like that. So either DRUPAL-7-UNSTABLE-2008-09-22 or DRUPAL-7-UNSTABLE-2008-39 (week 39 of 2008) would work for that. The regular schedule also makes it easier to "chase head", since you know and can predict when there will be a new stake in the ground. You can't predict when a given "tag-worthy" patch will land.

moshe weitzman’s picture

Glad we are finally doing this. I like the Zen of:


Ultimately, releases happen whenever the release maintainer (currently webchick) agrees that we need one. Thats what release management is all about. Its a lot like committing a patch - the community proposes the change and release mgr executes it.

dww’s picture

Title: Provide us with core developer snapshots » Provide us with core developer releases

A) Core's repo is different from contrib, and follows different validation rules. The rules are also easy to change, so don't let that worry anyone.

B) I agree that "unstable" is a good term to use for this. However, it should be "DRUPAL-7-0-UNSTABLE-1" to be consistent with our existing format for core tags. I think a sequence number is better than a date -- we're a completely international community, dates/timezones are weird, and it's a lot of extra goo in the tag names (more clumsy to refer to in email, issue text, IRC, etc). We don't date the alphas, betas or rcs, so why date these? The exact date is largely irrelevant, anyway.

C) I believe you're going to want release nodes, not just CVS tags:
C.1) You'll be able to refer to these versions in the issue queue.
C.2) Release nodes are required for update.module to be able to do anything.
C.3) You'll have release notes to show what changed since the last unstable release.
C.4) I don't think it's the end of the world if a .tar.gz exists, so long as it's pretty hard to find on the core project node. This is an area that needs help anyway, and that we'll be changing during the d.o redesign, so I'm not too worried about this. We can always come up with a short-term hack if necessary...

I guess all that remains is the nod from Dries.

I'm really glad this is finally happening. I might even be willing to start doing core development again. ;)


p.s. @litwol: Please don't edit your issue followups to change the content. It's totally confusing for people trying to follow these threads via email subscriptions. If you change your mind, add another comment saying so, but don't edit what you already wrote. Thanks.

webchick’s picture

Cool @ A) and B).

C) I believe you're going to want release nodes, not just CVS tags:

Hm. I /don't/ think so, but let's find out...

C.1) You'll be able to refer to these versions in the issue queue.

No... I'd rather not clutter up the versions list with potentially 50 or more unstable snapshots. This also pushes them in non-core developers' faces, which is exactly where they should NOT be.

In roughly 90% of the cases, core developers should continue to patch against HEAD. Developing against unstable tags would mainly be in the domain of "epic" patches like DBTNG or fields in core, or select few patches that touch lots of things. So it'd just be a matter of communicating in the issue which tag the patch is intended to apply against so reviewers can properly review them.

C.2) Release nodes are required for update.module to be able to do anything.

You should NOT be running an unstable release on any kind of serious site, therefore its interaction with update.module is largely irrelevant (and in fact, the lack of this could be seen as a feature rather than a bug). Save that for alpha/beta/RC releases, which we /do/ want people testing more widely.

C.3) You'll have release notes to show what changed since the last unstable release.

CHANGELOG.txt. We add one entry per tag, and then aggregate them all together when we're ready to generate an alpha.

C.4) I don't think it's the end of the world if a .tar.gz exists, so long as it's pretty hard to find on the core project node. This is an area that needs help anyway, and that we'll be changing during the d.o redesign, so I'm not too worried about this. We can always come up with a short-term hack if necessary...

Again, I want to emphasize that this should be a tool by developers, for developers. We should NOT expose end users to these releases, except where carefully guided; e.g. the usability team sets up a test server somewhere with a checkout of -r DRUPAL-7-0-UNSTABLE-347 and lets end users hammer away at it.

dww’s picture


"In roughly 90% of the cases, core developers should continue to patch against HEAD. Developing against unstable tags would mainly be in the domain of "epic" patches like DBTNG or fields in core, or select few patches that touch lots of things."

The VAST effort wasted continuously re-rolling core patches is a huge part of why I think this is a good thing. I'd say 90% of patches should be against the last unstable release, except for the most trivial 1-liner typo fixes or something. Only 10% of the time in the final days between "this is basically RTBC, now we just need it to apply to HEAD" should anyone bother working with HEAD itself. Maybe I'm over-stating these numbers a bit, but I think we should seriously reconsider our core development workflow and how we spend/waste each other's time in the issue queues with patches. So long as all tests are passing when you cut another unstable release (should be a hard-and-fast rule), then this shouldn't be much of a problem. Of course, there will always be some degree of "crap, 3 other patches that touch the same function already landed in HEAD, I have to re-roll", but it'd be a much lower cost than our current methodology, and generally speaking, there's going to be a smaller set of patches being rerolled simultaneously, since patches will spend a much smaller % of their lifecycle in the "rerolling hell" period.

All of which brings me back to the question of versions in the issue queue...

"I'd rather not clutter up the versions list with potentially 50 or more unstable snapshots. This also pushes them in non-core developers' faces, which is exactly where they should NOT be."

Then maybe the UI for the version selector needs a little help. Perhaps the options should be grouped by "6.x", then "5.x", then "7.x" or something. Sort of like how the project selector is split up into the types of projects, only not with 5000 options to select from. ;) We could also potentially add a flag to user profiles for "show all core versions when posting issues" or something, which defaulted to "off", but which active core developers could flip on. Or even just a "Show advanced options" JS checkbox that did some magic.

So it'd just be a matter of communicating in the issue which tag the patch is intended to apply against so reviewers can properly review them.

Not so. The key thing is that if people are rolling patches against 7.0-unstable4, they need to be able to say so in their issue. The only way the TestBot on will be able to do the right thing is if that issue has an actual version string that means something. Furthermore, it's going to be so much more useful for developers to use real issue versions to express what's going on or what has to happen next. All but the most trivial issues quickly become filled with noise and the signal is easily lost. Last thing I want to do is have to spend 15 minutes reading through a long confusing issue thread to figure out something that should be in the metadata summary table at the top of the issue.

IMHO, if we embrace unstable releases of core (which we should) we need to embrace it fully.

We should NOT expose end users to these releases

I totally agree. However, to make the most of these as "a tool by developers, for developers" then we need these to play nicely with our other developer tools, most importantly and the issue queues. That means release nodes. IMHO, the time saving potential of having unstable core releases is worth a few hours of project* hacking to sand off the rough spots if necessary.


sdboyer’s picture

Just chiming in quickly to note that I'm just as happy with a sequence number as I am with a date. No bike shedding here!

catch’s picture

"DRUPAL-7-0-UNSTABLE-1 is great - and easier to scan than a date.

I think I agree with dww about release nodes here going on #24 (and it's very easy to stumble upon 7.x-dev already, so that's a non-issue IMO as it relates to this particular proposal) - but presumably we could do tags initially and add in release nodes slightly later on when any necessary infrastructure is in place?

Michelle’s picture

I like the idea of actual release nodes / tarballs to download. CVS and I don't get along well. ;) I'm not a core dev, but I have a keen interest in core as it affects the forum module. So I would use this new system to periodically get a tarball to set up a test site and make sure AF still plays well with forum and also possibly attempt some core forum patches. I definitely agree that end users shouldn't be using these, but they are useful to more than just core devs.


Anonymous’s picture

+1 for #24 and release nodes.

Polish off the roughness and force the developers to do some additional work to get the update module and other systems to show the unstable releases. Give warnings that make unstable scary for normal users and most of them will leave it alone.

webchick’s picture

It appears I am out-voted on the release node stuff. :) Kinda sucks, cos that means it's going to take a good 15 minutes or so to make each one of these, rather than 30 seconds. Also means we're going to be blocked waiting for sanding of project module (while it's pending upgrading to 6.x, thus creating more stuff that needs to be ported) instead of rolling out this change immediately. :\

But ok, if you say so. :P

Michelle’s picture

Catch said: "but presumably we could do tags initially and add in release nodes slightly later on when any necessary infrastructure is in place?"

Is that doable? I know, for myself, I won't use this until D7 gets a bit farther along anyway. Maybe by then project will be sanded. :)


dww’s picture

There's no need to block this for anything.

a) Yes, make tags now and add release nodes later. Nothing wrong with that. I can trust the 5 people with commit access to the core repo not to move release tags just since there's no release node and validation scripts stopping you. ;)

b) testing.d.o doesn't fully work yet, so there's no need to make release nodes for that just yet. The backend for that stuff will probably have to be taught about these other possible versions of core it needs to checkout to test a given patch, anyway.

c) We can live without real version numbers in issues in the short term and see how it goes.

d) Even if you started making release nodes now, I'm not sure there's any sanding that we *must* do. Sanding just makes the furniture a little smoother and nicer to look at -- it's still sturdy and can hold your stuff just fine. ;)

e) @webchick: You lie. ;) "it's going to take a good 15 minutes or so to make each one of these, rather than 30 seconds" There's a script to automate the release notes, and you're going to have to go through that stuff to update the CHANGELOG.txt before you tag, anyway. I think release nodes will only add at most 2-5 minutes to this task... But, if we manage to spend an hour arguing about it before you ever make an unstable release, then we're sure to have come out ahead! ;)

All I'm saying is that sooner or later (probably sooner), we're going to want release nodes for these, too.

Pasqualle’s picture

maybe little off topic, but I would like to know:

1. how can I tag my module which works with DRUPAL-7-0-UNSTABLE-16?
2. can I make my unstable module release, or it will be an option only for core?

dww’s picture

@Pasqualle: Good questions. We can certainly amend the new rules from #252473: Prevent people from putting "-dev" in CVS tag names to allow "UNSTABLE" as another kind of "extra" tag for contrib releases. So, you'd do something like DRUPAL-7--1-0-UNSTABLE16 in contrib, which would show up as "7.x-1.0-unstable16", to say "here's the 7.x release of my module for 'unstable16' 7.x core".

chx’s picture

I disagree with release nodes because they take core committer time and that's a very precious resource. Equally I would not want update module to say anything, really. Update nodes, not needed. tar.gz -- flip the switch in ViewVC for those who can't use CVS. It can make shiny tarballs. Lastly, that then the issue queue can refer these -- there is some truth but can we hold off that a bit? It requires quite a bit of UI thinking which should not hold this one back.

kbahey’s picture

OK, so +1 on providing development snapshots.

I prefer to have the date in the name, but it seems the simpler form has more support, and I am cool with that.

Yes, let us start with tags only and see how things go, and not overburden webchick with snapshots. She would do cvs tag DRUPAL-7-0-UNSTABLE-1 and be done with it.

Question 1: If there are no releases, then how/where will these be listed so people know they exist? Will we have a page that pulls the tags from CVS, and lists them for all to know? Since we got rid of all php nodes, a good candidate for this is the project_stuff module which is part of the drupalorg project.

Question 2: If there are no release nodes, then the change log can be deduced using the cvs-release-notes.php script, given the tag and the one previous to it. Again, this is just a matter of documenting how to do that.

Dries’s picture

While this makes it easier for developers, it introduces more work for reviewers as well as committers. Personally, I prefer having to deal with one release/tag only.

That said, optimizing for speed of innovation and change is more important than optimizing for my workload, so I'm OK with this change. I can certainly see the value. As long we are willing to make that trade-off, this gets my approval.

I strongly prefer the "DRUPAL-7-0-UNSTABLE-1" format though.

Pasqualle’s picture

so? when and where?

hint: tomorrow will be October 1

webchick’s picture

I'd like to get all the current test failure patches committed first, as well as #281446: Add 'status report' for installer requirements so it can be field tested. I'll hopefully get a chance to look at those patches later tonight, but Oct. 1 sounds reasonable.

webchick’s picture :)

I did not create a release node, for two reasons:

7.x has "Recommended" selected, and there is no way to make it NOT recommended. :(

#2: It'll show up as an "official release" and that means that the second I create a release node, Update Status is going to go "Oh! Did you know there's also this new lovely version of Drupal available?"

Both of which are pretty much the opposite of what I'd like to say with these releases. ;)

I'm tempted to close this issue, since the question about "can we can we huh can we huh?" has effectively been answered. There are a few follow-up issues though it sounds like, including:

* Adjust the contributed modules regex to allow this too?
* Ability to add development releases that are static.. could also be used with regular alpha/beta, regardless of the outcome of the above discussion. I'm sure there's an issue for this somewhere. :)
* "Sanding" of project issue module.
* Adding "download a tarball of this" functionality to ViewCVS in lieu of release nodes.

dww’s picture


#1: You seem to have not been following #313090: Change all contrib module's "Recommended" labels to something else? or you'd know about #313827: make it possible to not have *any* branch recommended. ;)

#2: Not sure what you mean. update_status only tells you about your currently installed version of core. if you're on 6.x, it doesn't give a hoot about what's happening in 7.x. Only people using 7.x-dev running update.module would see anything about 7.0-unstable1 being available, and I think that's both reasonable and desirable.

a) "Adjust the contributed modules regex to allow this too?"

Hrm, not so sure they have that need. In general, contrib spends a lot less time in feature "thaw" and wild-west development than core does. Plus, contrib can always use a new branch for this and do releases on this (unrecommended) other branch if they want. Either that, or they're just porting to a new version, and there's not as great a need for point releases to roll patches and test against as with core. Finally, what's wrong with just calling these "alpha" releases for contrib? But, I guess I'm not fundamentally opposed, so if there's enough support for adding "UNSTABLE" to the allowed list of "extra" keywords you can use in a CVS tag, I'm willing to add the 9 total bytes to the regexp in the contrib repo's config file. ;)

b) "Ability to add development releases that are static."

I don't know what you're talking about. Isn't a "development release" by definition something dynamic that's regenerated from the end of a branch? If it's static, it's got a tag. If it's got a tag, it's an official release, although it can have all kinds of "extra" qualifiers to indicate it's not suitable for production use. Can you explain what you mean?

c) "'Sanding' of project issue module."

Here are some of the old issues about this that I had in mind if anyone's interested:
#97568: allow maintainers to restrict choices for "Version" in new issues/replies
#97569: allow filtering issue queue by "series"
However, the other idea I proposed in comment #24 above is now here:
#315583: Group and sort version options on the issue form
Not sure about the "show advanced options" idea -- there's no issue for that now, so if folks think it's a good idea, please create one in the project_issue queue...

d) "Adding "download a tarball of this" functionality to ViewCVS in lieu of release nodes."

active > won't fix. ;) Definitely not worth the trouble. I'd much rather see us fix these other issues (which can be useful for other things) then trying to touch ViewCVS and/or to build a hacky solution for generating and downloading tarballs on d.o itself.

webchick’s picture

#1: Nope. :P My head's down in the core queue these days, not in many other places. ;) But #313827: make it possible to not have *any* branch recommended is basically what I'm talking about, I think.

#2: Yep, you're right. I'm mistaken. That's if there's a 6.x-2.x branch or something that it'll do the behaviour I'm thinking of.

a) I am ambivalent on this point, since I try very hard not to ever work in contrib for too long at a time. ;) But there were some folks asking about it, either in this issue or in #drupal, so I bring it up as something to consider.

b) Sure. What I mean is that on a typical project releases table, there are two divisions: "Official releases" and "Development snapshots" (used the wrong term, sorry). I would like this 7.x-1.0-UNSTABLE-1 release node, if it existed, to show up under "Development Snapshots," NOT Official Releases, even though it's based off of a tag and not a branch. There is nothing "official" about this release at all, and currently it would show up at the *top* of the list and be the first thing people saw, also definitely not what I want.

c) Cool, sounds like some good avenues for people to explore if they're interested in these being shown in the UI differently.

d) Heh, ok. :)

litwol’s picture

shouldnt this be marked as fixed ?

dww’s picture

Status: Active » Fixed

@litwol: not until the last of the loose ends are tied up.

@webchick: cool. (b) Now makes sense, though I'm not sure how I'd handle that from the project admin UI perspective (e.g. -- the thing from your screenshot above), nor the end-user UI of that download table. But yeah, I guess we'd need a solution if we were going to do this, since having 7.0-unstable1 at the top of the download table would be A Bad Thing(tm), even with "unstable" in there. So, if anyone wants to work on this, see #315597: Make it possible to mark certain releases (e.g. unstable/alpha) as "development" releases.

Ok, I think that's everything, so yes, we can now call this fixed. ;)

p.s. YAY webchick for getting this started!

dww’s picture

p.p.s. warm fuzzy anecdote:

Earlier today, #315899: Update to D7 showed up on my projects. I wanted to test it, since I found it hard to believe a 2 line patch would port cvs_deploy to D7. ;) I went to go setup a D7 test site, so I did a "cvs up -A" in my D7 core checkout. install.php was giving a WSOD. :( My next step was "cvs up -r DRUPAL-7-0-UNSTABLE-1", I reloaded install.php, and lo, all worked perfectly! Now, 7.x-1.x-dev exists for cvs_deploy, which says "Initial support for D7 core (as of the UNSTABLE-1 tag)." COOL! ;)

Anonymous’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.