Hi Berin and Alberto,
I think Alberto's suggestion, with Berin's further addition for major
releases, makes sense. That's exactly how we did it in Xerces-J when
Xerces2-J was spun off: indeed, Xerces1 releases are still available and
the branch is still there if anyone cares to do anything with it.
So if a +1 is needed, here it is.
Cheers!
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: [EMAIL PROTECTED]
Berin Lautenbach
<[EMAIL PROTECTED] To: [EMAIL PROTECTED]
mes.org> cc:
Subject: Re: Release policy for
Xerces-C
02/10/2004 04:15
AM
Please respond to
xerces-c-dev
Alberto,
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,
Berin
Alberto 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
