Is bumping the version number evil, if it's not mandated by the PVP?
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. Should I bump a.b.C or even a.B to signal that it's worth using the new version or should I bump only a.b.c.D such that packages that depend on a.b get installed with the new version automatically? 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 disadvantages for others. Hence, I guess I should make a major version bump. Is it bad habit to make a major version bump if the API does not change? Maybe I should simply change the API too ;) Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)
Sebastian Fischer
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), then according to the PVP the minimum required is to bump a.b.c.D.
Should I bump a.b.C or even a.B to signal that it's worth using the new version or should I bump only a.b.c.D such that packages that depend on a.b get installed with the new version automatically?
I think this is the best approach overall, as the effects will be noticed by users immediately (rather than waiting for maintainers to notice there's a new version and be bothered to check if they can make their library use that new version: for example, HXT is using a version of tagsoup that is two major versions out of date). Making a big hue and cry about it on the mailing lists, planet.haskell.org, etc. might help draw attention to the nice new shiny performance with the added bonus of code using that library not having to change.
Hence, I guess I should make a major version bump. Is it bad habit to make a major version bump if the API does not change?
It depends on how many people use your library; if the number is small enough and manageable enough then you can try to get into contact with maintainers that use your library and make sure they expand the constraints on your package such that the new version is available to be used. -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
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 version or should I bump only a.b.c.D such that packages that depend on a.b get installed with the new version automatically?
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 disadvantages for others.
How would bumping the major version change that? Let's suppose a package depending on your declares a version constraint a.b.* (which would be good practice). If you bump the patch level, anyone installing the other package with get the latest version of your package; if you bump the major version, they won't, until the maintainer of the other package releases a new version to update their dependencies. (Some maintainers might be annoyed by that; if you annoy maintainers too much, they might look for less annoying dependencies.) Whenever you bump a version number, you are signalling that the new version is worth using. If you bump the patchlevel, you're also signalling that the new version is compatible with the old, so using it is a no-brainer.
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 disadvantages for others.
How would bumping the major version change that?
Right, it doesn't. 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.*. I actually like the idea of making a patch-level release *and* a new major release to get the best of both approaches. Do you think this is reasonable? On Aug 14, 2010, at 10:49 PM, wren ng thornton wrote:
Asymptotic improvements may very well be worth a C or B bump [...] If your library is _defined_ by its performance characteristics, then a C or B bump would be appropriate since the complexity is effectively part of the API
To make things clear, I will shortly release a new version of the primes package for efficient generation of prime numbers. The new version asymptotically improves memory usage. The point of the library is to generate primes efficiently, so a major version bump feels justified. However, as explained above, I plan to additionally make a patch-level release. Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)
Sebastian Fischer
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 disadvantages for others.
How would bumping the major version change that?
Right, it doesn't. 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)". This is necessary for whenever a bug-fix affecting your program was made in a dependency.
I actually like the idea of making a patch-level release *and* a new major release to get the best of both approaches. Do you think this is reasonable?
It could work, as that way users packages that use your library whose maintainers haven't updated the deps yet to use the new major version can still get the benefits of the improved speed. If you were to take this route, I would strongly advise stating in the Description that the new major version is API-compatible with the old one (with the major bump being for "advertising" reasons).
To make things clear, I will shortly release a new version of the primes package for efficient generation of prime numbers. The new version asymptotically improves memory usage. The point of the library is to generate primes efficiently, so a major version bump feels justified. However, as explained above, I plan to additionally make a patch-level release.
Well, Brent Yorgey seems to the be the only person who uses primes in a Hackage package [1], so maybe you can just do a major bump release and co-ordinate with him to bump his np-extras package? [1]: http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/primes-... -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com
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 than I initially thought. I have changed my mind and will probably make a patch-level release without an identical major release. (I'll make an additional major release with a generalised API however.) Thanks! Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.)
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 aren't (usually) earth shattering and so are probably only worth a D bump. Asymptotic improvements may very well be worth a C or B bump--- especially if they introduce the possibility of new bugs due to large code changes (i.e., you haven't _proven_ bug-for-bug compatibility). But it also depends on the audience. For example, some libraries are defined as being "an efficient implementation of Foo" rather than being, say, an implementation of a particular data type or a particular high-level API for writing nice code. If your library is _defined_ by its performance characteristics, then a C or B bump would be appropriate since the complexity is effectively part of the API even though it isn't captured in the type system. -- Live well, ~wren
participants (4)
-
Ivan Lazar Miljenovic -
Ross Paterson -
Sebastian Fischer -
wren ng thornton