I'm all for a maintenance release. I'm vaguely fearful about the
implications of leaving the DLL name the same, in that you'll have to
inspect the timestamp to know which version you've got. But the whole issue
of naming is irrelevant to me, since I build my own static library. Maybe
those who use the binary distributions will have more useful feedback.
This raises a question of process, however. Xerces-C releases feel sort of
arbitrary, in that there's a more-or-less constant stream of coding being
done that doesn't seem to slow or pause for a release. I'm not aware of a
testing cycle with a branch or code freeze followed by the issuing of
release candidates until one is deemed fit for formal release. (This seems
to work pretty well for the Mozilla project.) In my experience, to get a
good, stable version, you have to grab a nightly a week or two after a
numbered release, when the kinks have been ironed out.
This concern should not be allowed to interfere with this release, which
seems likely to be stable. However, it may provide some indication about how
releases should be named. If the team wants to continue with the current
release model, it makes sense to call this version 1.5.1, in recognition of
the fact that it adds stability but little functionality to the previous
release. If we want to add a testing cycle for future releases, it's more
defensible (though perhaps not optimal) to call this 1.6, in the hope that
incremental maintenance releases will be rare in the future.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
