[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.
Cheers,
-Derek (dww)
More information about the development
mailing list