Clarify jOOQ's stance on binary compatibility
This commit is contained in:
lukaseder
parent
3ed2fa8e48
commit
8fa8025de0
@ -1173,38 +1173,50 @@ object Test { //
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<p>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)</p>
|
||||
</html></content>
|
||||
</section>
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
@ -1472,38 +1472,50 @@ object Test { //
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<p>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)</p>
|
||||
</html></content>
|
||||
</section>
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
@ -2839,45 +2839,50 @@ fun main(args: Array<String>) {
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
@ -2838,45 +2838,50 @@ fun main(args: Array<String>) {
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
@ -2865,8 +2865,9 @@ fun main(args: Array<String>) {
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
@ -2876,7 +2877,7 @@ fun main(args: Array<String>) {
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
@ -2888,12 +2889,16 @@ fun main(args: Array<String>) {
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)
|
||||
</p>
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
|
||||
@ -1521,45 +1521,50 @@ object Test { //
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
|
||||
<p>
|
||||
jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
@ -1981,45 +1981,50 @@ DSL.using(sql.connection)
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
@ -2479,45 +2479,50 @@ DSL.using(sql.connection)
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
@ -2679,45 +2679,50 @@ DSL.using(sql.connection)
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
@ -2683,45 +2683,50 @@ DSL.using(sql.connection)
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
@ -2826,45 +2826,50 @@ fun main(args: Array<String>) {
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
@ -2840,45 +2840,50 @@ fun main(args: Array<String>) {
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
@ -2839,45 +2839,50 @@ fun main(args: Array<String>) {
|
||||
</html></content>
|
||||
</section>
|
||||
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<p>
|
||||
jOOQ follows the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a> quite strictly. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
<section id="semantic-versioning">
|
||||
<title>jOOQ and backwards-compatibility</title>
|
||||
<content><html>
|
||||
<h3>Semantic versioning</h3>
|
||||
<p>
|
||||
jOOQ's understanding of backwards compatibility is inspired by the rules of semantic versioning according to <a href="http://semver.org">http://semver.org</a>. Those rules impose a versioning scheme [X].[Y].[Z] that can be summarised as follows:
|
||||
</p>
|
||||
<ul>
|
||||
<li>If a patch release includes bugfixes, performance improvements and API-irrelevant new features, [Z] is incremented by one.</li>
|
||||
<li>If a minor release includes backwards-compatible, API-relevant new features, [Y] is incremented by one and [Z] is reset to zero.</li>
|
||||
<li>If a major release includes backwards-incompatible, API-relevant new features, [X] is incremented by one and [Y], [Z] are reset to zero.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break. That is why there is at most one major release per year, which changes only those parts of jOOQ's API and functionality, which were agreed upon on the user group. During the year, only minor releases are shipped, adding new features in a backwards-compatible way
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rule should be observed:
|
||||
</p>
|
||||
<h3>jOOQ's understanding of backwards-compatibility</h3>
|
||||
<p>
|
||||
Backwards-compatibility is important to jOOQ. You've chosen jOOQ as a strategic SQL engine and you don't want your SQL to break.
|
||||
</p>
|
||||
<p>
|
||||
However, there are some elements of API evolution that would be considered backwards-incompatible in other APIs, but not in jOOQ. As discussed later on in the section about <reference id="dsl-and-non-dsl" title="jOOQ's query DSL API"/>, much of jOOQ's API is indeed an internal domain-specific language implemented mostly using Java interfaces. Adding language elements to these interfaces means any of these actions:
|
||||
</p>
|
||||
<ul>
|
||||
<li>Adding methods to the interface</li>
|
||||
<li>Overloading methods for convenience</li>
|
||||
<li>Changing the type hierarchy of interfaces</li>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>)
|
||||
It becomes obvious that it would be impossible to add new language elements (e.g. new <reference id="column-expressions" title="SQL functions"/>, new <reference id="select-statement" title="SELECT clauses"/>) to the API without breaking any client code that actually implements those interfaces. Hence, the following rules should be observed:
|
||||
</p>
|
||||
|
||||
<ul>
|
||||
<li>jOOQ's DSL interfaces should not be implemented by client code! Extend only those extension points that are explicitly documented as "extendable" (e.g. <reference id="custom-queryparts" title="custom QueryParts"/>).</li>
|
||||
<li>Binary compatibility can be expected from patch releases, but not from minor releases as it is not practical to maintain binary compatibility in an internal DSL.</li>
|
||||
<li>Source compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Behavioural compatibility can be expected from patch and minor releases.</li>
|
||||
<li>Any jOOQ SPI <code>XYZ</code> that is meant to be implemented ships with a <code>DefaultXYZ</code> or <code>AbstractXYZ</code>, which can be used safely as a default implementation.</li>
|
||||
</ul>
|
||||
|
||||
<h3>jOOQ-codegen and jOOQ-meta</h3>
|
||||
<p>
|
||||
While a reasonable amount of care is spent to maintain these two modules under the rules of semantic versioning, it may well be that minor releases introduce backwards-incompatible changes. This will be announced in the respective release notes and should be the exception.
|
||||
</p>
|
||||
</html></content>
|
||||
</section>
|
||||
</html></content>
|
||||
</section>
|
||||
</sections>
|
||||
</section>
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user