Subject: policy -- upgrading peer libraries
From: Paul Rohr (paul@abisource.com)
Date: Tue Aug 21 2001 - 13:37:25 CDT
AKA, don't fall off the giant:
http://www.abisource.com/mailinglists/abiword-dev/01/August/0604.html
Once we've done all the XP integration work to introduce a dependency on a
peer library, we could theoretically keep building AbiWord forever without
ever touching that library again. This is a Good Thing.
However, since few software products ever reach perfection (hah!), it's
often the case that the maintainers of that peer library will improve it in
ways that we'd like to take advantage of. This is also a Good Thing.
Thus, from time to time, someone will assert that it's time to upgrade our
copy of libfoo from version x.y to x.z so that we can take advantage of
their improved barbaz support. A version upgrade is sometimes a good idea
for its own sake, but it's usually not worth going to all that trouble until
someone's ready to implement an AbiWord feature that really *needs* good
barbaz support.
In the spirit of the "donut rule", here are my proposed criteria for
checking in such an upgrade:
1. You warn people ahead of time, especially if you'll need to recruit
folks to help with integration on other platforms.
2. You carry forward all mods in our existing CVS version that aren't
reflected upstream, unless you know for sure that they're no longer
relevant.
3. You do checkins to our CVS peer module in ways which don't muddy or
truncate the history. Knowing the difference between each of the
following versions is a Good Thing:
- what we had in CVS
- what we have there now
- what the upstream version contains, and thus
- what our localized mods, if any, are.
If you're not sure how to do this, ask.
4. You ensure that it continues to build cleanly and works on *all*
platforms, not just yours.
5. If step #4 requires any patches, you submit them upstream.
bottom line
-----------
The intended effect should be obvious.
All other developers get a heads up message that the peer library is in
flux, so they know to grab a clean copy of the current working version.
Then, at some later point, they get a commit message confirming that it's
safe to do a cvs update of that library.
The whole time their trees Just Build -- first with the old library version,
and then with the new library version.
Paul
This archive was generated by hypermail 2b25 : Tue Aug 21 2001 - 13:29:38 CDT