Semantic versioning - Revision history

JaroslavTulach at 19:22, 12 May 2012

2012-05-12T19:22:42Z

←Older revision		Revision as of 19:22, 12 May 2012
Line 3:		Line 3:
	This [[proximity]] is best explained by another [[semantic versioning]] [http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf proposal] defined by [[OSGi]] guys. It is using [[range dependencies]] to distinguish between [[ClientAPI]] (always uses major dependencies range like 1.x to 2.0) and [[ProviderAPI]] (which is supposed to always depend on 1.x to 1.(x+1) micro range). This style of versioning opens the [[vendor library]] [[proximity]] category up to a bit more distant [[ProviderAPI\|providers]]. If the [[OSGi]] [[semantic versioning]] is obeyed, one can use [[Final interface]] as a contract between [[ClientAPI\|clients of your API]] and [[ProviderAPI\|providers of your API]]. It is expected that in case there is an incompatible change in the [[Final interface]], you bump up the micro version.		This [[proximity]] is best explained by another [[semantic versioning]] [http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf proposal] defined by [[OSGi]] guys. It is using [[range dependencies]] to distinguish between [[ClientAPI]] (always uses major dependencies range like 1.x to 2.0) and [[ProviderAPI]] (which is supposed to always depend on 1.x to 1.(x+1) micro range). This style of versioning opens the [[vendor library]] [[proximity]] category up to a bit more distant [[ProviderAPI\|providers]]. If the [[OSGi]] [[semantic versioning]] is obeyed, one can use [[Final interface]] as a contract between [[ClientAPI\|clients of your API]] and [[ProviderAPI\|providers of your API]]. It is expected that in case there is an incompatible change in the [[Final interface]], you bump up the micro version.

-	Althrough common design practise in [[OSGi]] world the drawbacks are obvious. Every change into the [[API]] renders all existing providers invalid (as the new version of library is out of their micro [[dependency]] range). With every such change all providers need to be rewritten. Should there be two providers written against different version of the [[~~API~~]] they are unlikely to co-exist together.	+	Althrough common design practise in [[OSGi]] world the drawbacks are obvious. Every change into the [[API]] renders all existing providers invalid (as the new version of [[library]] is out of their micro [[dependency]] range). With every such change all [[ProviderAPI\|providers]] need to be rewritten. Should there be two providers written against different version of the [[library]] they are unlikely to co-exist together (because of versioning, otherwise they very likely could as commonly the case in [[modular library\|modular libraries]]).

	Due to these limitations I call this library style a '''few to many''' [[proximity]]. It is possible to have multiple [[ProviderAPI\|providers]], but as they use micro range, there can never be as much providers as clients. In case you seek real '''many to many''' [[proximity]] consider using [[modular library]] design.		Due to these limitations I call this library style a '''few to many''' [[proximity]]. It is possible to have multiple [[ProviderAPI\|providers]], but as they use micro range, there can never be as much providers as clients. In case you seek real '''many to many''' [[proximity]] consider using [[modular library]] design.

JaroslavTulach at 19:20, 12 May 2012

2012-05-12T19:20:11Z

←Older revision		Revision as of 19:20, 12 May 2012
Line 1:		Line 1:
	[[Semantic versioning]] is a natural interpretation of [[dependencies]] as described in manifesto at [http://semver.org/ semver.org]. It is also a base for designing [[library\|libraries]] with [[semantic versioning\|few to many]] [[proximity]] between their [[ClientAPI]] and [[ProviderAPI]] sides.		[[Semantic versioning]] is a natural interpretation of [[dependencies]] as described in manifesto at [http://semver.org/ semver.org]. It is also a base for designing [[library\|libraries]] with [[semantic versioning\|few to many]] [[proximity]] between their [[ClientAPI]] and [[ProviderAPI]] sides.

-	~~There~~ is ~~also~~ another ~~proposal for~~ [http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf ~~semantic versioning~~] defined by [[OSGi]] guys. It is using [[range dependencies]] to distinguish between [[ClientAPI]] (always uses major dependencies range like 1.x to 2.0) and [[ProviderAPI]] (which is supposed to always depend on 1.x to 1.(x+1) micro range). This style of versioning opens the [[vendor library]] [[proximity]] category up to a bit more distant [[ProviderAPI\|providers]]. If the [[OSGi]] [[semantic versioning]] is obeyed, one can use [[Final interface]] as a contract between [[ClientAPI\|clients of your API]] and [[ProviderAPI\|providers of your API]]. It is expected that in case there is an incompatible change in the [[Final interface]], you bump up the micro version.	+	This [[proximity]] is best explained by another [[semantic versioning]] [http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf proposal] defined by [[OSGi]] guys. It is using [[range dependencies]] to distinguish between [[ClientAPI]] (always uses major dependencies range like 1.x to 2.0) and [[ProviderAPI]] (which is supposed to always depend on 1.x to 1.(x+1) micro range). This style of versioning opens the [[vendor library]] [[proximity]] category up to a bit more distant [[ProviderAPI\|providers]]. If the [[OSGi]] [[semantic versioning]] is obeyed, one can use [[Final interface]] as a contract between [[ClientAPI\|clients of your API]] and [[ProviderAPI\|providers of your API]]. It is expected that in case there is an incompatible change in the [[Final interface]], you bump up the micro version.

	Althrough common design practise in [[OSGi]] world the drawbacks are obvious. Every change into the [[API]] renders all existing providers invalid (as the new version of library is out of their micro [[dependency]] range). With every such change all providers need to be rewritten. Should there be two providers written against different version of the [[API]] they are unlikely to co-exist together.		Althrough common design practise in [[OSGi]] world the drawbacks are obvious. Every change into the [[API]] renders all existing providers invalid (as the new version of library is out of their micro [[dependency]] range). With every such change all providers need to be rewritten. Should there be two providers written against different version of the [[API]] they are unlikely to co-exist together.

	Due to these limitations I call this library style a '''few to many''' [[proximity]]. It is possible to have multiple [[ProviderAPI\|providers]], but as they use micro range, there can never be as much providers as clients. In case you seek real '''many to many''' [[proximity]] consider using [[modular library]] design.		Due to these limitations I call this library style a '''few to many''' [[proximity]]. It is possible to have multiple [[ProviderAPI\|providers]], but as they use micro range, there can never be as much providers as clients. In case you seek real '''many to many''' [[proximity]] consider using [[modular library]] design.

JaroslavTulach at 19:19, 12 May 2012

2012-05-12T19:19:15Z

←Older revision		Revision as of 19:19, 12 May 2012
Line 1:		Line 1:
-	[[Semantic versioning]] is a natural interpretation of [[dependencies]] as described in manifesto at [http://semver.org/ semver.org].	+	[[Semantic versioning]] is a natural interpretation of [[dependencies]] as described in manifesto at [http://semver.org/ semver.org]. It is also a base for designing [[library\|libraries]] with [[semantic versioning\|few to many]] [[proximity]] between their [[ClientAPI]] and [[ProviderAPI]] sides.

	There is also another proposal for [http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf semantic versioning] defined by [[OSGi]] guys. It is using [[range dependencies]] to distinguish between [[ClientAPI]] (always uses major dependencies range like 1.x to 2.0) and [[ProviderAPI]] (which is supposed to always depend on 1.x to 1.(x+1) micro range). This style of versioning opens the [[vendor library]] [[proximity]] category up to a bit more distant [[ProviderAPI\|providers]]. If the [[OSGi]] [[semantic versioning]] is obeyed, one can use [[Final interface]] as a contract between [[ClientAPI\|clients of your API]] and [[ProviderAPI\|providers of your API]]. It is expected that in case there is an incompatible change in the [[Final interface]], you bump up the micro version.		There is also another proposal for [http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf semantic versioning] defined by [[OSGi]] guys. It is using [[range dependencies]] to distinguish between [[ClientAPI]] (always uses major dependencies range like 1.x to 2.0) and [[ProviderAPI]] (which is supposed to always depend on 1.x to 1.(x+1) micro range). This style of versioning opens the [[vendor library]] [[proximity]] category up to a bit more distant [[ProviderAPI\|providers]]. If the [[OSGi]] [[semantic versioning]] is obeyed, one can use [[Final interface]] as a contract between [[ClientAPI\|clients of your API]] and [[ProviderAPI\|providers of your API]]. It is expected that in case there is an incompatible change in the [[Final interface]], you bump up the micro version.

JaroslavTulach at 19:11, 12 May 2012

2012-05-12T19:11:06Z

←Older revision		Revision as of 19:11, 12 May 2012
Line 1:		Line 1:
	[[Semantic versioning]] is a natural interpretation of [[dependencies]] as described in manifesto at [http://semver.org/ semver.org].		[[Semantic versioning]] is a natural interpretation of [[dependencies]] as described in manifesto at [http://semver.org/ semver.org].

-	There is also another proposal for [http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf semantic versioning] defined by [[OSGi]] guys. It is using [[range dependencies]] to distinguish between [[ClientAPI]] (always uses major dependencies range like 1.x to 2.0) and [[ProviderAPI]] (which is supposed to always depend on 1.x to 1.(x+1) micro range). This style of versioning opens the [[vendor library]] [[proximity]] category up to a bit more distant [[ProviderAPI\|providers]]. If the [[OSGi]] [[semantic versioning]] is obeyed, one can use [[~~FinalInterface~~]] as a contract between [[ClientAPI\|clients of your API]] and [[ProviderAPI\|providers of your API]]. It is expected that in case there is an incompatible change in the [[~~FinalInterface~~]], you bump up the micro version.	+	There is also another proposal for [http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf semantic versioning] defined by [[OSGi]] guys. It is using [[range dependencies]] to distinguish between [[ClientAPI]] (always uses major dependencies range like 1.x to 2.0) and [[ProviderAPI]] (which is supposed to always depend on 1.x to 1.(x+1) micro range). This style of versioning opens the [[vendor library]] [[proximity]] category up to a bit more distant [[ProviderAPI\|providers]]. If the [[OSGi]] [[semantic versioning]] is obeyed, one can use [[Final interface]] as a contract between [[ClientAPI\|clients of your API]] and [[ProviderAPI\|providers of your API]]. It is expected that in case there is an incompatible change in the [[Final interface]], you bump up the micro version.

	Althrough common design practise in [[OSGi]] world the drawbacks are obvious. Every change into the [[API]] renders all existing providers invalid (as the new version of library is out of their micro [[dependency]] range). With every such change all providers need to be rewritten. Should there be two providers written against different version of the [[API]] they are unlikely to co-exist together.		Althrough common design practise in [[OSGi]] world the drawbacks are obvious. Every change into the [[API]] renders all existing providers invalid (as the new version of library is out of their micro [[dependency]] range). With every such change all providers need to be rewritten. Should there be two providers written against different version of the [[API]] they are unlikely to co-exist together.

	Due to these limitations I call this library style a '''few to many''' [[proximity]]. It is possible to have multiple [[ProviderAPI\|providers]], but as they use micro range, there can never be as much providers as clients. In case you seek real '''many to many''' [[proximity]] consider using [[modular library]] design.		Due to these limitations I call this library style a '''few to many''' [[proximity]]. It is possible to have multiple [[ProviderAPI\|providers]], but as they use micro range, there can never be as much providers as clients. In case you seek real '''many to many''' [[proximity]] consider using [[modular library]] design.

JaroslavTulach at 19:00, 12 May 2012

2012-05-12T19:00:48Z

←Older revision		Revision as of 19:00, 12 May 2012
Line 1:		Line 1:
-	A natural interpretation of [[dependencies]] as described in manifesto at http://semver.org/	+	[[Semantic versioning]] is a natural interpretation of [[dependencies]] as described in manifesto at [http://semver.org/ semver.org].
		+
		+	There is also another proposal for [http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf semantic versioning] defined by [[OSGi]] guys. It is using [[range dependencies]] to distinguish between [[ClientAPI]] (always uses major dependencies range like 1.x to 2.0) and [[ProviderAPI]] (which is supposed to always depend on 1.x to 1.(x+1) micro range). This style of versioning opens the [[vendor library]] [[proximity]] category up to a bit more distant [[ProviderAPI\|providers]]. If the [[OSGi]] [[semantic versioning]] is obeyed, one can use [[FinalInterface]] as a contract between [[ClientAPI\|clients of your API]] and [[ProviderAPI\|providers of your API]]. It is expected that in case there is an incompatible change in the [[FinalInterface]], you bump up the micro version.
		+
		+	Althrough common design practise in [[OSGi]] world the drawbacks are obvious. Every change into the [[API]] renders all existing providers invalid (as the new version of library is out of their micro [[dependency]] range). With every such change all providers need to be rewritten. Should there be two providers written against different version of the [[API]] they are unlikely to co-exist together.
		+
		+	Due to these limitations I call this library style a '''few to many''' [[proximity]]. It is possible to have multiple [[ProviderAPI\|providers]], but as they use micro range, there can never be as much providers as clients. In case you seek real '''many to many''' [[proximity]] consider using [[modular library]] design.

JaroslavTulach: New page: A natural interpretation of dependencies as described in manifesto at http://semver.org/

2012-01-07T12:37:03Z

New page: A natural interpretation of dependencies as described in manifesto at http://semver.org/

New page

A natural interpretation of [[dependencies]] as described in manifesto at http://semver.org/