Just to be sure I understand, as I understand it with the versioning (major.minor.patch) :
x.x.x -> x.x.y then there is an implication that ABI remains the same.
x.x.x -> x.y.z then there is an implication the API remains the same (or at least is only extended). I.e. a recompile of reliant apps is expected to work.
x.x.x ->a.b.c then there is an implication of an API change (i.e. recompile will break for reliant apps).
So for a major version number change (where the API breaks), you might actually consider running a separate branch for a period of time, with an expectation that bug fixes would be applied to both HEAD and last major branch.
Cheers,
BerinAlberto Massari wrote:
Hi,
as Neil wrote in his message announcing Xerces-C 2.5, this upcoming release should probably have been called 2.4.1.
This raised a little debate (involving also other projects inside the Apache group), so we thought it could be useful to try to describe the current (informal) release policy and put it up to the list for vote/approval/criticism/feedback etc...
So here it is:
1) we don't try to enforce binary compatibility between each public release; that is, we will release a major.minor version every now and then (when a certain number of bug fixes/new features have been added? when Xalan or XML Security want to ship a new release using new features and needs a public version of Xerces?) and almost never issue a major.minor.patch version.
2) If a showstopper bug is encountered with a release, a patch release may be
considered. If no commit has been made on the trunk which would result in
binary incompatibility, and no commit has been made that is not thought to
be release-quality, then the patch release can be created by tagging the
trunk; otherwise, a branch will need to be created and the show stopper
fixed there.
3) any normal bug is fixed only in the HEAD branch, and the user is responsible for building a patch against the special version she is using
Feedback is welcome.
Alberto
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
