JustCode - Revision history

JaroslavTulach: /* Drawbacks */

2017-06-06T08:51:26Z

Drawbacks

←Older revision		Revision as of 08:51, 6 June 2017
Line 39:		Line 39:


-	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.

JaroslavTulach: /* History */

2017-06-06T08:49:45Z

History

←Older revision		Revision as of 08:49, 6 June 2017
Line 29:		Line 29:
	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 ==

JaroslavTulach: /* History */

2017-06-06T08:49:15Z

History

←Older revision		Revision as of 08:49, 6 June 2017
Line 29:		Line 29:
	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 ==

JaroslavTulach: /* History */

2017-06-06T08:48:48Z

History

←Older revision		Revision as of 08:48, 6 June 2017
Line 29:		Line 29:
	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 ==

JaroslavTulach: /* History */

2017-06-06T08:48:18Z

History

←Older revision		Revision as of 08:48, 6 June 2017
Line 29:		Line 29:
	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 ==

JaroslavTulach: /* In the Code */

2017-06-06T08:47:02Z

In the Code

←Older revision		Revision as of 08:47, 6 June 2017
Line 36:		Line 36:


-	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.	+	== Drawbacks ==
		+
		+
		+	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.

JaroslavTulach: /* In the Code */

2017-06-06T08:44:58Z

In the Code

←Older revision		Revision as of 08:44, 6 June 2017
Line 36:		Line 36:


-	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.

JaroslavTulach: /* In the Code */

2017-06-06T08:44:40Z

In the Code

←Older revision		Revision as of 08:44, 6 June 2017
Line 36:		Line 36:


-	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.

JaroslavTulach: /* In the Code */

2017-06-06T08:44:14Z

In the Code

←Older revision		Revision as of 08:44, 6 June 2017
Line 34:		Line 34:

	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.
		+
		+
		+	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.

JaroslavTulach: /* History */

2017-06-06T08:39:37Z

History

←Older revision		Revision as of 08:39, 6 June 2017
Line 29:		Line 29:
	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.