Geez, I'm not going to make it to the end of p-dev mail today...
BAW> Maybe I misunderstand, but it makes me really nervous that micro
BAW> releases would have internal incompatibilities (I'm not talking
BAW> about those related to fixed bugs in earlier micros).
It depends on what branch you're on. Following up on my previous note about
functional completeness, one of your goals might be "to investigate MAL's
new Unicode implementation". You might get to 2.5.7 and realize it's not
going to work for some reason and then have to rip it back out. Obviously
2.5.8 might then be incompatible with 2.5.7, but since it's the current
bleeding edge development branch, you never advertise stability across point
releases. Clearly, this sort of toss-it-in-rip-it-out sort of thing
wouldn't hold in the Garth branch.
BAW> I'd dread having to explain to people "this is compatible with
BAW> Python Python 2.4.2 but not anything earlier than 2.4.1 unless
BAW> you're on the 2.3.x branch and then 2.3.7 is okay, but not 2.3.6 or
BAW> earlier."
That's just it. You *never, never, never* require *any* development release
to run an external package. If you release a package that requires that
sort of coupling, Guido simply calls in a favor from one of his Italian
cousins in the Soprano or Corleone families (my apologies for the crude
American Mafia-style references, Alex), and they take care of you. :-)
Skip
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4