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

[Darrel O'Pry]

On Mon, 2008-03-10 at 16:38 -0700, Derek Wright wrote:
> 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.

I didn't know how end users would react, or how it would work on d.o.
until it got rolled out. I thought part of the development process was
learning from each release, and improving it.. maybe I'm mistaken about
the 'release early, release often' philosophy.

> > 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).

Sorry, I don't exactly pay close attention to the dev list. I'm probably
not the only maintainer who doesn't watch this list closely. I think it
is unfair to expect me, as a maintainer, to be responsible for watching
this list as general traffic increases.  (regardless of what you hack
for your day job.)

Maybe a special mailing list for notifying maintainers of issues that
impact them.

My belated position is, I think support is too loaded for how it will be
used and sets an expectation that module maintainers will hop to it and
fix end user problems. 

> > 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...".

I don't think having a flag for supported and recommended on each
release would be a usability pain. I don't think people would screw it
up, and it's simple to tick a check box. 

I also think  maintainers should have to be proactive about setting a
release to be 'supported' or 'recommended'. Especially, now that core
ships with update_status.module. This is a question you likely only have
to answer once... and a little bit of doc on the release node and the
checkboxes will go a long way.

And yes if I want it to work differently I understand I have to code it
myself, deal with getting community support for the changes, nurse the
patch for who knows how long to get everyone to agree that it can be
committed, and then hope and pray some day my sweat and labor gets into
core or on d.o. 

> 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.

then we have a bug, cuz my releases with -extra are appearing on my
project page as supported and recommended. This could be the cause of
some of my consternation.

see: http://drupal.org/project/filefield
see: http://drupal.org/project/imagefield

> 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:

No you already helped me figure that out...