Hello,
On Aug 14, 2010, at 12:43 PM, Ross Paterson wrote:
When bumping only a.b.c.D, the new version is not installed as a
dependency if the old version already is installed (unless the new
version is explicitly demanded.) It seems bumping a.b.c.D has
advantages for some users and
Sebastian Fischer s...@informatik.uni-kiel.de writes:
Hello,
On Aug 14, 2010, at 12:43 PM, Ross Paterson wrote:
When bumping only a.b.c.D, the new version is not installed as a
dependency if the old version already is installed (unless the new
version is explicitly demanded.) It seems
My worry with bumping only the patch level is that
people who explicitly want to depend on the efficient version of my
library need to depend on a.b.c.D and cannot follow the good practice
of depending on a.b.*.
Well, then you have = a.b.c.d a.(b+1).
Ok, it seems this is less of an issue
Sebastian Fischer s...@informatik.uni-kiel.de writes:
Hello,
I wonder whether (and how) I should increase the version number of a
library when the API does not change but the implementation gets more
efficient.
If the API remains the same (and the behaviour of the functions does as
well),
[CC'ing café again]
On Aug 14, 2010, at 12:25 PM, Max Rabkin wrote:
On Sat, Aug 14, 2010 at 11:13 AM, Sebastian Fischer
s...@informatik.uni-kiel.de wrote:
Hello,
I wonder whether (and how) I should increase the version number of
a library
when the API does not change but the implementation
On Sat, Aug 14, 2010 at 11:13:19AM +0200, Sebastian Fischer wrote:
I wonder whether (and how) I should increase the version number of a
library when the API does not change but the implementation gets
more efficient.
Should I bump a.b.C or even a.B to signal that it's worth using the
new
Sebastian Fischer wrote:
Hello,
I wonder whether (and how) I should increase the version number of a
library when the API does not change but the implementation gets more
efficient.
I think it depends on how much more efficient. Constant factors of
improvement are always nice, but they
