[development] Announcing DRUPAL-7-0-UNSTABLE-2

Derek Wright drupal at dwwright.net
Tue Oct 14 08:00:22 UTC 2008

On Oct 13, 2008, at 12:23 PM, Larry Garfield wrote:

> They can and should "chase unstable", as that's exactly what we  
> want them to be doing.

The point of having upgrade docs split up by UNSTABLE-N is precisely  
to make it easier for contrib maintainers to "chase unstable".   
cvs_deploy is currently ported to UNSTABLE-1.  It'd be nice if I  
could just look somewhere and see what APIs changed between  
UNSTABLE-1 and UNSTABLE-2 that would require further porting to keep  
cvs_deploy working in UNSTABLE-2.  Anyone "chasing unstable" is in  
the same boat.

Yes, I could figure it out via reading through all the CVS log  
messages since UNSTABLE-1, but that's time consuming and contains a  
lot of noise if the signal I'm looking for are API changes that would  
break my module(s).  Since there's no release node for UNSTABLE-2,  
and webchick decided not to mess with documenting these things by  
unstable version in CHANGELOG.txt, there's no good place to see the  
relevant changes since UNSTABLE-1.

While we were hashing all this out in IRC, webchick suggested  
splitting up the module upgrade docs by UNSTABLE version, so at least  
there'd be somewhere (where contrib authors are looking anyway) to  
see all API changes between each unstable.

If this high-signal info is not in CHANGELOG.txt, there's not a  
release node, and it's not in the upgrade docs, where do y'all  
propose to put it?  If there's no such high-signal info anywhere, it  
makes "chasing unstable" more of a chore, and you can bet fewer  
contrib maintainers will bother.

-Derek (dww)

More information about the development mailing list