Branching for 3.3 work?

["Cantor, Scott" <ca...@osu.edu>]

There's an open bug or two that probably would need to lead to an API bump from 3.2 and the suggestion was made that even if we may not have a ton of active effort, there may be value in allowing such work to occur if the cycles to do it happen to be available.

I don't have any problems personally with agreeing to apply the small number of changes that are likely to both branches in the interim, so I'm fine branching 3.2 off for maintenance and leaving master for other work if the rest of the PMC doesn't object.

If anybody objects, let me know, otherwise I can branch it next week.

-- Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

RE: Branching for 3.3 work?

["Cantor, Scott" <ca...@osu.edu>]

> That's what I was planning on. There's no hurry on the doc update, but I'll
> branch probably Wednesday barring any objections.

Branch is pushed this morning as xerces-3.2, so master is open for 3.3 business.

I will try and get the web site pages cleaned up a bit with information about the "open" branches and the state of the tree. And will have to dual commit that, sigh.

-- Scott


---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: Branching for 3.3 work?

["Cantor, Scott" <ca...@osu.edu>]

On 3/9/20, 12:01 PM, "Boris Kolpackov" <bo...@codesynthesis.com> wrote:

> Sounds good to me. I, personally, think we don't even need a vote
> for this. Maybe if you don't hear any opposing views, just make the
> change?

That's what I was planning on. There's no hurry on the doc update, but I'll branch probably Wednesday barring any objections.

-- Scott

Re: Branching for 3.3 work?

[Boris Kolpackov <bo...@codesynthesis.com>]

Cantor, Scott <ca...@osu.edu> writes:

> On 3/6/20, 9:56 AM, "Boris Kolpackov" <bo...@codesynthesis.com> wrote:
> 
> > I am not aware though from the names internal/ and dom/impl/ should be
> > off-limits while everything else is probably fair game.
> 
> I'm happy if we decide we just say that since it addresses this
> particular case, but names aside I don't think there was a formal
> page saying it. If we agree on that, I can do an update the release
> policy material to expand it to "Versioning and API policy".

Sounds good to me. I, personally, think we don't even need a vote
for this. Maybe if you don't hear any opposing views, just make the
change?

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: Branching for 3.3 work?

["Cantor, Scott" <ca...@osu.edu>]

On 3/6/20, 9:56 AM, "Boris Kolpackov" <bo...@codesynthesis.com> wrote:

> I am not aware though from the names internal/ and dom/impl/ should be
> off-limits while everything else is probably fair game.

I'm happy if we decide we just say that since it addresses this particular case, but names aside I don't think there was a formal page saying it. If we agree on that, I can do an update the release policy material to expand it to "Versioning and API policy".

> The documentation is in "What are the release policies for Xerces-C++?":

Right, but it's the question of what actually is an API that I didn't think was formally addressed, leaving one to assume all of it is.

-- Scott

Re: Branching for 3.3 work?

[Boris Kolpackov <bo...@codesynthesis.com>]

Cantor, Scott <ca...@osu.edu> writes:

> I may have mispoke in that issue too: is there any formal definition of
> which include directories are "API" and which should be off limits for
> library clients?

I am not aware though from the names internal/ and dom/impl/ should be
off-limits while everything else is probably fair game.


> I'm not aware of any such documentation so my impression is compatibly
> changing any callable or inheritable API (thus the ABI) would be a minor
> bump.

The documentation is in "What are the release policies for Xerces-C++?":

https://xerces.apache.org/xerces-c/faq-contributing-3.html#faq-2

In summary, patch releases are ABI-compatible, minor -- API compatible
but not necessarily ABI-compatible (thus dependents must be recompiled),
and major are API-breaking.

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: Branching for 3.3 work?

["Cantor, Scott" <ca...@osu.edu>]

On 3/6/20, 9:23 AM, "Boris Kolpackov" <bo...@codesynthesis.com> wrote:

> Ok, makes sense, thanks.

There's also apparently some movement on 2188 from the Debian team, they may have a fix for the open security issue, but it may require a 3.3 anyway.

I may have mispoke in that issue too: is there any formal definition of which include directories are "API" and which should be off limits for library clients? I'm not aware of any such documentation so my impression is compatibly changing any callable or inheritable API (thus the ABI) would be a minor bump.

-- Scott

Re: Branching for 3.3 work?

[Boris Kolpackov <bo...@codesynthesis.com>]

Cantor, Scott <ca...@osu.edu> writes:

> Normally I wouldn't be keen to branch now if the next patch was to 3.2,
> but because the changes are so minimal now, maintaining patches to two
> branches would not be very much work.

Ok, makes sense, thanks.

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: Branching for 3.3 work?

["Cantor, Scott" <ca...@osu.edu>]

On 3/6/20, 12:01 AM, "Boris Kolpackov" <bo...@codesynthesis.com> wrote:

> Just to confirm my understanding, you would like to create the 3.2-series
> branch in order to release 3.2.3 with some cherry-picked commits, correct?

That's the intended branch, but the purpose isn't to immediately release a 3.2.3, it's to enable some amount of future work that would have to be done as a 3.3, without preventing another 3.2 patch.

> If so, I am wondering why not instead go ahead and release master as 3.3?

There isn't any specific ommitment to do the work on a particular schedule. Since the current set of committers are all largely not able to work steadily on Xerces, it was a way of allowing work that somebody wanted to do to happen on whatever schedule they can manage so that if they happen to have some time, there's nothing stopping them.

Normally I wouldn't be keen to branch now if the next patch was to 3.2, but because the changes are so minimal now, maintaining patches to two branches would not be very much work.

-- Scott



---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org

Re: Branching for 3.3 work?

[Boris Kolpackov <bo...@codesynthesis.com>]

Cantor, Scott <ca...@osu.edu> writes:

> There's an open bug or two that probably would need to lead to an API bump
> from 3.2 and the suggestion was made that even if we may not have a ton of
> active effort, there may be value in allowing such work to occur if the
> cycles to do it happen to be available.
>
> I don't have any problems personally with agreeing to apply the small number
> of changes that are likely to both branches in the interim, so I'm fine
> branching 3.2 off for maintenance and leaving master for other work if the
> rest of the PMC doesn't object.

Just to confirm my understanding, you would like to create the 3.2-series
branch in order to release 3.2.3 with some cherry-picked commits, correct?

If so, I am wondering why not instead go ahead and release master as 3.3?

---------------------------------------------------------------------
To unsubscribe, e-mail: c-dev-unsubscribe@xerces.apache.org
For additional commands, e-mail: c-dev-help@xerces.apache.org