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