[development] releases, recommended/supported changing automatically on release creation...

[Derek Wright]

On Mar 10, 2008, at 11:42 AM, Darrel O'Pry wrote:

> I find a lot of the terminology and workflow around the new release  
> system very confusing...

Then please pay attention and help when I ask for input, don't just  
complain about it months later when I've already invested the time to  
implement something and roll it out on d.o.

> supported I don't think is a good word... It implies more than I  
> want it to... like my dev and rc releases aren't 'supported', but  
> they're maintained, and I want them displayed for the brave who  
> want to test them, but I don't want to commit myself to supporting  
> them.

Again -- this was a big deal for the D6 string freeze, since  
update_status has to know what terminology to use when reporting this  
stuff in the admin UI.  At the time, "supported" vs. "unsupported"  
was what the core committers preferred, so that's what I went with.   
I think it'd be even more confusing if update_status and project*  
used different terminology.

#include "you-missed-your-chance-to-complain.h"  (I hack C/C++ for my  
day job).

> I'm also really confused about why we tie releases to branches and  
> not the release nodes.... I want to set releases to supported or  
> recommended... not branches of my code... branches are not  
> synonymous to releases...

Which branch(es) of your code you're still supporting and which one  
you're currently recommending that new users install is specific to a  
branch ("release series" if you will), not an individual release.   
It'd be a huge pain and many people would screw this up and forget to  
bump this setting if you had to remember to change this every time  
you make a new release.  If you want it to work differently, you get  
to: a) write the code yourself, and b) handle every support request  
that ever comes in about "I made a new release but it's not showing  
up on my project page...".

Basically, the point of the new functionality is to handle the case  
where you've got multiple branches for the same version of core --  
which "release series" should users downloading your module for the  
first time grab the latest release from?  Which branch(es) should  
show up on the project node as code you expect to work.  In the  
common case, you've got a single branch, so it's easy: that branch is  
both supported and recommended, and the latest official release  
(without extra) should show up on the project page.  If there are  
multiple branches, we have to know which one we should pull the  
latest release from, and which branch(es) you're still supporting.

If you don't yet understand how branches correspond to release  
series, you need to listen to the talk I gave at DrupalCon, or at  
least read the 2 page handout I made:

http://boston2008.drupalcon.org/files/maintain-release-handout.pdf

Not sure what's up with the audio recordings of the sessions.  I  
bootlegged my own talk, so I could post the .mp3 on the session page  
if that'd be best.

-Derek (dww)