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)