In my previous mail I talked about some ideas to ease transitions. I've
thought over this a bit more and come up with several different
approaches which could be used. Here is a list with their pros (+) and
cons (-). Bear in mind that in all cases most of the work will be done
for you by
Hi Matthew,
thank you for your ideas but I still see a problem.
On Sun, Aug 2, 2009 at 5:53 PM, Matthew Johnsonmj...@debian.org wrote:
In the list below when I say version I mean API version not
upstream release version. API version changes when upstream change the
API and is encoded in the
On Sun Aug 02 20:00, Torsten Werner wrote:
upstream release version. API version changes when upstream change the
API and is encoded in the package name.
How do I find out if the API has changed in a new upstream version?
As others have said: read the changelog, test it, look at the diffs.
On Sun Aug 02 20:39, Marcus Better wrote:
Separate -dev packages
--
The heavy-weight approach that is most like C and relies on the package
manager a lot.
+ build-depends don't change between versions
By this you mean we build-depend on a virtual package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ludovic Claude wrote:
I have recently packaged the clirr tool which does exactly that: give it
2 versions of a jar, and it will report any API breaking changes.
Nice, looks useful, but note that it only detects visible API changes, not
more subtle
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthew Johnson wrote:
By this you mean we build-depend on a virtual package like libfoo-dev,
which is Provided by libfoo0-dev, libfoo1-dev and so on?
Well, there's two ways of doing this in C libraries. Some provide
versionned -dev packages and
6 matches
Mail list logo
