markhibberd · March 8, 2013 05:36 · techtangents · Mar 8, 2013
diff --git a/rant.txt b/rant.txt
 Why do I believe this distinction is important?

 Versions are virtual, the express intent not reality. Artifacts are real. How
 they are idenitified is up for debate but I am of the belief it is not and 
 never can be versions.

 As a concrete example, if I am using cabal and make the statement that I depend on 
 version 1.7.* of library barney, I am not stating that I think I work with all
 versions of barney that start with 1.7, I am merely stating that my expectations
 are that I am compatible with version 1.7 of barney and *believe* that barney intends 
 to convey some semantics with that version number and will modify the number if it 
 changes. I am entering into a contract of trust, but it is a contract I must have if
 I want to work effectively with barney. If barney breaks that contract - I should 
 reconsider and determine whether my expectations were incorrect or was barney a complete 
 arsehole. 

 This is where I believe cabal (and pretty much every dependency tool) dies. It stops there. 
 I have not, and can not, make any claims as to correctness. I do not know what artifacts,
 version 1.7.* encompasses, and I would argue you that you can not (even if the dependency
 was stricter - 1.7.1), so how can I claim that I work with them.

 This flows on to what I wanted to accomplish with chalk. There should be versions that
 specify intent, but there should also be identifiers that track real artifacts (a hash
 or signature being the most easily consumable representations). This is where it becomes
 important to link building, testing and publishing. I think I should be able to publish
 metadata that represents real artifacts, and clients should be able to leverage that 
 metadata. I can publish something that depends on 1.7.*, but has been built with ac1df12e 
 and fee1fbf1 clients should have the ability to say I don't care give me 1.7.* or give
 me something that has been verified with a specific build (to what extent means you are 
 in a trust relationship with the publisher, but a more useful one). The more useful 
 metadata you have, the more awesome the client can be. For example: "I want all these
 dependencies, with a preference for stable, and a preference for something that has been 
 tested with experimental compliler flag x." 

 I want this to be true. And it sucks every day that I don't have this level of tooling.
	Why do I believe this distinction is important?

	Versions are virtual, the express intent not reality. Artifacts are real. How
	they are idenitified is up for debate but I am of the belief it is not and
	never can be versions.

	As a concrete example, if I am using cabal and make the statement that I depend on
	version 1.7.* of library barney, I am not stating that I think I work with all
	versions of barney that start with 1.7, I am merely stating that my expectations
	are that I am compatible with version 1.7 of barney and believe that barney intends
	to convey some semantics with that version number and will modify the number if it
	changes. I am entering into a contract of trust, but it is a contract I must have if
	I want to work effectively with barney. If barney breaks that contract - I should
	reconsider and determine whether my expectations were incorrect or was barney a complete
	arsehole.

	This is where I believe cabal (and pretty much every dependency tool) dies. It stops there.
	I have not, and can not, make any claims as to correctness. I do not know what artifacts,
	version 1.7.* encompasses, and I would argue you that you can not (even if the dependency
	was stricter - 1.7.1), so how can I claim that I work with them.

	This flows on to what I wanted to accomplish with chalk. There should be versions that
	specify intent, but there should also be identifiers that track real artifacts (a hash
	or signature being the most easily consumable representations). This is where it becomes
	important to link building, testing and publishing. I think I should be able to publish
	metadata that represents real artifacts, and clients should be able to leverage that
	metadata. I can publish something that depends on 1.7.*, but has been built with ac1df12e
	and fee1fbf1 clients should have the ability to say I don't care give me 1.7.* or give
	me something that has been verified with a specific build (to what extent means you are
	in a trust relationship with the publisher, but a more useful one). The more useful
	metadata you have, the more awesome the client can be. For example: "I want all these
	dependencies, with a preference for stable, and a preference for something that has been
	tested with experimental compliler flag x."

	I want this to be true. And it sucks every day that I don't have this level of tooling.
No results found