The proposal to put new, incompatible version into new package does not imply any additional maintenance of old versions.
And BTW, other versioning approaches do not prevent from support of previous versions. These two questions are completely orthogonal.
If speak about old versions maintenance (in whatever versioning).
People using old versions should understand that development focus is shifted to the latest versions.
OTOH if someone has large application depending on say hunchentoot 0.13.0 and it is easier to accept his patch that for him to migrate to hunchentoot 1.2.18 - why not, create a branch from 0.13.0 and commit his patch.
21.11.2013, 15:01, "Stelian Ionescu" sionescu@cddr.org:
Since CL library development isn't subsidized by generous companies - like in the Java, Python & Ruby world - the best we can do with limited resources is break an API, maintain the project name and simply require all users to forward-port their code.
How the requirement for additional work in clients (which are probably other open source libraries) is a resource saving?
There are examples when it takes years to forward-port some libraries, due to incompatible changes in the dependencies.
When we do not break clients, it saves resources of their authors, and prevents CL library world from degradation.
20.11.2013, 18:55, "Robert P. Goldman" rpgoldman@sift.info:
I am not convinced by your argument that having old library versions is a no-cost solution. For those old > library versions to be of any value, they will have to be maintained
The value of the old versions is the possibility for existing clients to remain working. Maintenance is not required.
But this is an empirical question! Although pessimistic, I'd be happy to be wrong, and encourage you to go forth and test out your principles.
Thanks! When I have a situation where incompatible change is needed I will definitely consider this option. I also encourage others who is about to make incompatible changes to consider this approach and ask advice from the community.
Best regards, - Anton