| Re: [jgit-dev] [VOTE] Making API incompatible changes |
On Fri, Jun 21, 2013 at 4:44 PM, Matthias Sohn <matthias.sohn@xxxxxxxxx> wrote:
On Sat, Jun 22, 2013 at 1:13 AM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:
On Fri, Jun 21, 2013 at 3:41 PM, Matthias Sohn <matthias.sohn@xxxxxxxxx> wrote:...
> On Fri, Jun 21, 2013 at 4:21 PM, Gunnar Wagenknecht <gunnar@xxxxxxxxxxxxxxx>
> wrote:
>>
>> That doesn't sound right to me. IMO it's time for some semantic
>> versioning.
>> http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
>>
>> The API you mention sounds like a service provider API, i.e. it's used to
>> provide additional services to JGit. The proposed API change is backwards
>> compatible for consumers of the API. It is a breaking change for providers
>> of the API. According to the semantic versioning scheme, this requires a
>> bump up of the minor version part only.
>>
>> Thus, my proposal for this kind of change is:
>> 3.0 -> 3.1
>
>
> I wasn't aware of this rule, after having read this paper I think you are
> right
> after having read the semantic versioning paper again with Gunnar'sOK so our next version should be 3.1?
> comment I think this isn't necessary and we can do this as part of 3.1 since
> it looks to me this is an API to be implemented by providers of the API
> and following rule 3 on page 7 of the semantic versioning paper this
> translates to a minor version change. I wasn't aware of this rule earlier.
+1Related, is there some easy way to tell when authoring one of these API changes whether there are already pending breaking API changes in master that haven't been released?