Question

Consider this, we have a set of APIs to be released and that are most likely to be re-designed from bottom up in the future, would leaving the versioning at package level for backward compatibility so that users can always get the latest release without worrying about breaking their codes better than to release different library versions where backward compatibility is not always guaranteed if users are not sticking to a certain released version?

e.g. MyClass-LATEST.jar, which has package MyClass.v1; and then in the future provide package MyClass.v2; while keeping MyClass.v1 in the same library MyClass-LATEST.jar as oppose to releasing MyClass-vX.X-RELEASE.jar...

Cheers

Was it helpful?

Solution

I would not put the version number in the API. If you release a version that is not backward compatible, the user does not need to upgrade. But if you make a release is backward compatible, such as a bug fix version, you will force the user to change their package names without just being able to drop in a new jar.

Build tools (ant, maven, gradle, etc) are used for managing versions. You shouldn't need to do so in your API package names.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top