Revisions to Should the commit history be used to convey critical information to developers?

fix grammar

edit approved Dec 21, 2014 at 2:02

103
5

During a meeting regarding the rollback of a third-party SDK from the latest version it was noted that the our had developers already flagged in the commit history that the latest version should not be used.

Some developers argued that this was a bad practice and thereit should have instead been somethingnoted either in the source file (i.e. // Don't upgrade SDK Version x.y.z, see ticket 1234) or in a project level README file. Others argued that since the commit history is part of the project documentation it is an acceptable location for such information since we should all be reading it anyway.

Should the commit history be used to convey critical information to other developers or should such information be duplicated to another location such as a project README or comments in the relevant source file?

During a meeting regarding the rollback of a third-party SDK from the latest version it was noted that the our had developers already flagged in the commit history that the latest version should not be used.

Some developers argued that this was a bad practice and there should have been something either in the source file (i.e. // Don't upgrade SDK Version x.y.z, see ticket 1234) or in a project level README file. Others argued that since the commit history is part of the project documentation it is an acceptable location for such information since we should all be reading it anyway.

Should the commit history be used to convey critical information to other developers or should such information be duplicated to another location such as a project README or comments in the relevant source file?

During a meeting regarding the rollback of a third-party SDK from the latest version it was noted that the our developers already flagged in the commit history that the latest version should not be used.

Some developers argued that this was a bad practice and it should have instead been noted either in the source file (i.e. // Don't upgrade SDK Version x.y.z, see ticket 1234) or in a project level README file. Others argued that since the commit history is part of the project documentation it is an acceptable location for such information since we should all be reading it anyway.

Should the commit history be used to convey critical information to other developers or should such information be duplicated to another location such as a project README or comments in the relevant source file?

added 2 characters in body

Source Link

edited Dec 19, 2014 at 21:38

MetaFight

11.6k
3
47
75

During a meeting regarding the rollback of a third-party SDK from the latest version it was noted that the SDKour had developers already announcedflagged in the commit history that the latest version should not be used.

Some developers argued that this was a bad practice and there should have been something either in the source file (i.e. // Don't upgrade SDK Version x.y.z, see ticket 1234) or in a project level README file. Others argued that since the commit history is part of the project documentation it is an acceptable location for such information since we should all be reading it anyway.

Should the commit history be used to convey critical information to other developers or should such information be duplicated to another location such as a project README or comments in the relevant source file?

During a meeting regarding the rollback of a third-party SDK from the latest version it was noted that the SDK developers already announced in the commit history that the latest version should not be used.

Some developers argued that this was a bad practice and there should have been something either in the source file (i.e. // Don't upgrade SDK Version x.y.z, see ticket 1234) or in a project level README file. Others argued that since the commit history is part of the project documentation it is an acceptable location for such information since we should all be reading it anyway.

Should the commit history be used to convey critical information to other developers or should such information be duplicated to another location such as a project README or comments in the relevant source file?

During a meeting regarding the rollback of a third-party SDK from the latest version it was noted that the our had developers already flagged in the commit history that the latest version should not be used.

Some developers argued that this was a bad practice and there should have been something either in the source file (i.e. // Don't upgrade SDK Version x.y.z, see ticket 1234) or in a project level README file. Others argued that since the commit history is part of the project documentation it is an acceptable location for such information since we should all be reading it anyway.

Should the commit history be used to convey critical information to other developers or should such information be duplicated to another location such as a project README or comments in the relevant source file?

Great question that will be featured at Ars Techinca this weekend. I tried to make the first sentence a little less ambiguous, plus fixed a couple minor grammar choices.

Source Link

edit approved Dec 19, 2014 at 21:36

samthebrand

368
2
12
27

Recently a conversation came up duringDuring a meeting regarding the rollback of a third-party SDK from the latest version and it was noted that the fact it shouldn't be used wasSDK developers already announced in the commit history that the latest version should not be used. Other

Some developers argued that this was a bad practice and there should have been something either in the source file (i.e. // Don't upgrade SDK Version x.y.z, see ticket 1234) or in a project level README file. The othersOthers argued that since the commit history is part of the project documentation that it is an acceptable location for such information since we should all be reading it anyway.

As such, shouldShould the commit history be used to convey critical information to other developers or should such information be duplicated to another location such as a project README or comments in the relevant source file?

Recently a conversation came up during a meeting regarding the rollback of a third-party SDK from the latest version and it was noted that the fact it shouldn't be used was already in the commit history. Other developers argued that this was a bad practice and there should have been something either in the source file (i.e. // Don't upgrade SDK Version x.y.z, see ticket 1234) or in a project level README file. The others argued that since the commit history is part of the project documentation that it is an acceptable location for such information since we should all be reading it anyway.

As such, should the commit history be used to convey critical information to other developers or should such information be duplicated to another location such as a project README or comments in the relevant source file?

During a meeting regarding the rollback of a third-party SDK from the latest version it was noted that the SDK developers already announced in the commit history that the latest version should not be used.

Some developers argued that this was a bad practice and there should have been something either in the source file (i.e. // Don't upgrade SDK Version x.y.z, see ticket 1234) or in a project level README file. Others argued that since the commit history is part of the project documentation it is an acceptable location for such information since we should all be reading it anyway.

Should the commit history be used to convey critical information to other developers or should such information be duplicated to another location such as a project README or comments in the relevant source file?