Probably one still wants a [[BinaryCompatibility|binary compatible]] check as well as the '''change check''': changing some [[API]] shall yield a warning, but changing something incompatibly (with respect to already released version) needs to trigger an alert. Such system would result in two ''.sigtest'' files being in the repository - one capturing the last release and one capturing the current state. How to instruct developers to freely adjust the ''current state'' one and almost never touch the ''last released version'' is an additional organization problem. But it is similar to the need to update the ''.sigfile'' content once a release is one - some things can't be [[JustCode]], some things require certain level of developer discipline.

Probably one still wants a [[BinaryCompatibility|binary compatible]] check as well as the '''change check''': changing some [[API]] shall yield a warning, but changing something incompatibly (with respect to already released version) needs to trigger an alert. Such system would result in two ''.sigtest'' files being in the repository - one capturing the last release and one capturing the current state. How to instruct developers to freely adjust the ''current state'' one and almost never touch the ''last released version'' is an additional organization problem. But it is similar to the need to update the ''.sigfile'' content once a release is done - some things can't be [[JustCode]], some things require certain level of developer discipline.

One problem with [[BinaryCompatibility]] is that it isn't only a function of current state, but also of the previous one. This is similar to running benchmarks - you aren't concerned just about the current state, but also about the changes. Did we speed something up since yesterday? Did we regress? Such approach needs to ''step out'' of the code and create a system that maintains the history. Usually teams create a database and store the results in it.

One problem with [[BinaryCompatibility]] is that it isn't only a function of current state, but also of the previous one. This is similar to running benchmarks - you aren't concerned just about the current state, but also about the changes. Did we speed something up since yesterday? Did we regress? Such approach needs to ''step out'' of the code and create a system that maintains the history. Usually teams create a database and store the results in it.

The same can be done with [[API]]s and the current [[TruffleSigtest#Notification of Daily Changes|Truffle API check]] was doing exactly that. It remembered the previous [[netbeans:Sigtest|signatures]] of the [[API]] and after each commit compared them with their new state. If there is a difference it sends an email. The hope is to give people an early alert of changes, so they can fix their (potential) mistakes before the release.

The same can be done with [[API]]s and the current [[TruffleSigtest#Notification of Daily Changes|Truffle API check]] was doing exactly that. It remembered the previous [[netbeans:Sigtest|signatures]] of the [[API]] and after each commit compared them with their new state. If there was a difference it sent an email. The hope was to give people an early alert of changes, so they could fix their (potential) mistakes before the release.

== In the Code ==

== In the Code ==

One problem with [[BinaryCompatibility]] is that it isn't only a function of current state, but also of the previous one. This is similar to running benchmarks - you aren't concerned just about the current state, but also about the changes. Did we speed something up since yesterday? Did we regress? Such approach needs to ''step out'' of the code and create a system that maintains the history. Usually teams create a database and store the results in it.

One problem with [[BinaryCompatibility]] is that it isn't only a function of current state, but also of the previous one. This is similar to running benchmarks - you aren't concerned just about the current state, but also about the changes. Did we speed something up since yesterday? Did we regress? Such approach needs to ''step out'' of the code and create a system that maintains the history. Usually teams create a database and store the results in it.

The same can be done with [[API]]s and the current [[TruffleSigtest#Notification of Daily Changes|Truffle API check]] was doing exactly that. It remembered the previous [[netbeans:Sigtest|signatures]] of the [[API]] and after each commit compares them with their new state. If there is a difference it sends an email. The hope is to give people an early alert of changes, so they can fix their (potential) mistakes before the release.

The same can be done with [[API]]s and the current [[TruffleSigtest#Notification of Daily Changes|Truffle API check]] was doing exactly that. It remembered the previous [[netbeans:Sigtest|signatures]] of the [[API]] and after each commit compared them with their new state. If there is a difference it sends an email. The hope is to give people an early alert of changes, so they can fix their (potential) mistakes before the release.

== In the Code ==

== In the Code ==

One problem with [[BinaryCompatibility]] is that it isn't only a function of current state, but also of the previous one. This is similar to running benchmarks - you aren't concerned just about the current state, but also about the changes. Did we speed something up since yesterday? Did we regress? Such approach needs to ''step out'' of the code and create a system that maintains the history. Usually teams create a database and store the results in it.

One problem with [[BinaryCompatibility]] is that it isn't only a function of current state, but also of the previous one. This is similar to running benchmarks - you aren't concerned just about the current state, but also about the changes. Did we speed something up since yesterday? Did we regress? Such approach needs to ''step out'' of the code and create a system that maintains the history. Usually teams create a database and store the results in it.

The same can be done with [[API]]s and the current [[TruffleSigtest#Notification of Daily Changes|Truffle API check]] was doing exactly that. It remembers the previous [[netbeans:Sigtest|signatures]] of the [[API]] and after each commit compares them with their new state. If there is a difference it sends an email. The hope is to give people an early alert of changes, so they can fix their (potential) mistakes before the release.

The same can be done with [[API]]s and the current [[TruffleSigtest#Notification of Daily Changes|Truffle API check]] was doing exactly that. It remembered the previous [[netbeans:Sigtest|signatures]] of the [[API]] and after each commit compares them with their new state. If there is a difference it sends an email. The hope is to give people an early alert of changes, so they can fix their (potential) mistakes before the release.

== In the Code ==

== In the Code ==

One problem with [[BinaryCompatibility]] is that it isn't only a function of current state, but also of the previous one. This is similar to running benchmarks - you aren't concerned just about the current state, but also about the changes. Did we speed something up since yesterday? Did we regress? Such approach needs to ''step out'' of the code and create a system that maintains the history. Usually teams create a database and store the results in it.

One problem with [[BinaryCompatibility]] is that it isn't only a function of current state, but also of the previous one. This is similar to running benchmarks - you aren't concerned just about the current state, but also about the changes. Did we speed something up since yesterday? Did we regress? Such approach needs to ''step out'' of the code and create a system that maintains the history. Usually teams create a database and store the results in it.

The same can be done with [[API]]s and the current [[TruffleSigtest#Notification of Daily Changes|Truffle API check]] does exactly that. It remembers the previous [[netbeans:Sigtest|signatures]] of the [[API]] and after each commit compares them with their new state. If there is a difference it sends an email. The hope is to give people an early alert of changes, so they can fix their (potential) mistakes before the release.

The same can be done with [[API]]s and the current [[TruffleSigtest#Notification of Daily Changes|Truffle API check]] was doing exactly that. It remembers the previous [[netbeans:Sigtest|signatures]] of the [[API]] and after each commit compares them with their new state. If there is a difference it sends an email. The hope is to give people an early alert of changes, so they can fix their (potential) mistakes before the release.

== In the Code ==

== In the Code ==

Probably one still wants an [[BinaryCompatibility|binary compatible]] check as well as the '''change check''': changing some [[API]] shall yield a warning, but changing something incompatibly (with respect to already released version) needs to trigger an alert. Such system would result in two ''.sigtest'' files being in the repository - one capturing the last release and one capturing the current state. How to instruct developers to freely adjust the ''current state'' one and almost never touch the ''last released version'' is an additional organization problem.

 

 

Probably one still wants a [[BinaryCompatibility|binary compatible]] check as well as the '''change check''': changing some [[API]] shall yield a warning, but changing something incompatibly (with respect to already released version) needs to trigger an alert. Such system would result in two ''.sigtest'' files being in the repository - one capturing the last release and one capturing the current state. How to instruct developers to freely adjust the ''current state'' one and almost never touch the ''last released version'' is an additional organization problem. But it is similar to the need to update the ''.sigfile'' content once a release is one - some things can't be [[JustCode]], some things require certain level of developer discipline.

Probably one still wants an [[BinaryComptibility|binary compatible]] check as well as the '''change check''': changing some [[API]] shall yield a warning, but changing something incompatibly (with respect to already released version) needs to trigger an alert. Such system would result in two ''.sigtest'' files being in the repository - one capturing the last release and one capturing the current state. How to instruct developers to freely adjust the ''current state'' one and almost never touch the ''last released version'' is an additional organization problem.

Probably one still wants an [[BinaryCompatibility|binary compatible]] check as well as the '''change check''': changing some [[API]] shall yield a warning, but changing something incompatibly (with respect to already released version) needs to trigger an alert. Such system would result in two ''.sigtest'' files being in the repository - one capturing the last release and one capturing the current state. How to instruct developers to freely adjust the ''current state'' one and almost never touch the ''last released version'' is an additional organization problem.

Probably one still wants an [[BinaryComptible]] check as well as the '''change check''': changing some [[API]] shall yield a warning, but changing something incompatibly (with respect to already released version) needs to trigger an alert. Such system would result in two ''.sigtest'' files being in the repository - one capturing the last release and one capturing the current state. How to instruct developers to freely adjust the ''current state'' one and almost never touch the ''last released version'' is an additional organization problem.

Probably one still wants an [[BinaryComptibility|binary compatible]] check as well as the '''change check''': changing some [[API]] shall yield a warning, but changing something incompatibly (with respect to already released version) needs to trigger an alert. Such system would result in two ''.sigtest'' files being in the repository - one capturing the last release and one capturing the current state. How to instruct developers to freely adjust the ''current state'' one and almost never touch the ''last released version'' is an additional organization problem.

However similar effect could be achieved by storing the exact signatures in the [[Git]] repository and failing the build if they differ. That would require everyone who makes an [[API]] change to perform an additional step: to update the ''.sigtest'' files stored in the repository. That is somewhat annoying, but the benefit is clear - the knowledge of what is and what isn't an [[API]] is encoded directly in the code - e.g. all we need is [[JustCode]] - there is no need for additional [[Jenkins]] builders and keeping the history - the snapshot of the [[API]] is part of the [[Git]] state and always in sync with the code.

However similar effect could be achieved by storing the exact signatures in the [[Git]] repository and failing the build if they differ. That would require everyone who makes an [[API]] change to perform an additional step: to update the ''.sigtest'' files stored in the repository. That is somewhat annoying, but the benefit is clear - the knowledge of what is and what isn't an [[API]] is encoded directly in the code - e.g. all we need is [[JustCode]] - there is no need for additional [[Jenkins]] builders and keeping the history - the snapshot of the [[API]] is part of the [[Git]] state and always in sync with the code.

One problem with [[BinaryCompatibility]] is that it isn't only a function of current state, but also of the previous one. This is similar to running benchmarks - you aren't concerned just about the current state, but also about the changes. Did we speed something up since yesterday? Did we regress? Such approach needs to ''step out'' of the code and create a system that maintains the history. Usually teams create a database and store the results in it.

One problem with [[BinaryCompatibility]] is that it isn't only a function of current state, but also of the previous one. This is similar to running benchmarks - you aren't concerned just about the current state, but also about the changes. Did we speed something up since yesterday? Did we regress? Such approach needs to ''step out'' of the code and create a system that maintains the history. Usually teams create a database and store the results in it.

The same can be done with [[API]]s and the current [[TruffleSigtest#Notification of Daily Changes|Truffle API check]] does exactly that. It remembers the previous [[netbeans:Sigtest|signatures]] of the [[API]] and after each commit compares them with their new state. If there is a difference it sends an email. The hope was to give people an early alert of changes, so they can fix their (potential) mistakes before the release.

The same can be done with [[API]]s and the current [[TruffleSigtest#Notification of Daily Changes|Truffle API check]] does exactly that. It remembers the previous [[netbeans:Sigtest|signatures]] of the [[API]] and after each commit compares them with their new state. If there is a difference it sends an email. The hope is to give people an early alert of changes, so they can fix their (potential) mistakes before the release.

== In the Code ==

== In the Code ==

However similar effect could be achieved by storing the exact signatures in the [[Git]] repository and failing the build if they differ. That would require everyone who makes an [[API]] change to perform an additional step: to update the ''.sigtest'' files stored in the repository. That is somewhat annoying, but the benefit is clear - the knowledge of what is and what isn't an [[API]] is encoded directly in the code - e.g. all we need is [[JustCode]] - there is no need for additional [[Jenkins]] builders and keeping the history - the snapshot of the [[API]] is part of the [[Git]] state and always in sync with the code.

However similar effect could be achieved by storing the exact signatures in the [[Git]] repository and failing the build if they differ. That would require everyone who makes an [[API]] change to perform an additional step: to update the ''.sigtest'' files stored in the repository. That is somewhat annoying, but the benefit is clear - the knowledge of what is and what isn't an [[API]] is encoded directly in the code - e.g. all we need is [[JustCode]] - there is no need for additional [[Jenkins]] builders and keeping the history - the snapshot of the [[API]] is part of the [[Git]] state and always in sync with the code.