Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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.
>> 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's
> 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.

OK so our next version should be 3.1?


Related, 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?
jgit-dev mailing list

Back to the top