Hi everyone. I'm looking for some sponsorship for this package. The
current packaging is available in my public_git repository:
http://anonscm.debian.org/cgit/pkg-java/jackson-dataformat-yaml.git/tree/de
bian
On 26/10/14 6:07 AM, "Markus Koschany" wrote:
>> I managed to get all of this done,
* Thorsten Glaser:
> On Tue, 28 Oct 2014, Emmanuel Bourg wrote:
>
>> like to highlight that in Java you can't have two incompatible versions
>> of the same library on the classpath. So if elasticsearch pulls another
>> library that depends on guava but is incompatible with the version 18,
>> it's
* Emmanuel Bourg:
> There is another point worth discussing I think. When we want to fork a
> package foo 1.0 because the version 2.0 is incompatible, do we:
>
> 1. duplicate the package foo as foo-1 and upgrade foo to the version 2.
> Every reverse dependency that doesn't work with the version ha
On Tue, Oct 28, 2014 at 03:29:33PM +, Stephen Nelson wrote:
> On Tue, Oct 28, 2014 at 2:38 PM, Emmanuel Bourg wrote:
>
> > There is another point worth discussing I think. When we want to fork a
> > package foo 1.0 because the version 2.0 is incompatible, do we:
> >
> > 1. duplicate the packa
On Tue, Oct 28, 2014 at 2:38 PM, Emmanuel Bourg wrote:
> There is another point worth discussing I think. When we want to fork a
> package foo 1.0 because the version 2.0 is incompatible, do we:
>
> 1. duplicate the package foo as foo-1 and upgrade foo to the version 2.
> Every reverse dependency
* Emmanuel Bourg:
> Le 27/10/2014 16:07, Hilko Bengen a écrit :
>
>> 1. Testing whether a rebuild against the newer version still works is
>> clearly not sufficient: code can be loaded at run-time, for instance.
> True, but that's more the exception than the rule, and I don't think
> many projects
There is another point worth discussing I think. When we want to fork a
package foo 1.0 because the version 2.0 is incompatible, do we:
1. duplicate the package foo as foo-1 and upgrade foo to the version 2.
Every reverse dependency that doesn't work with the version has to be
updated to use the n
On Tue, 28 Oct 2014, Emmanuel Bourg wrote:
> like to highlight that in Java you can't have two incompatible versions
> of the same library on the classpath. So if elasticsearch pulls another
> library that depends on guava but is incompatible with the version 18,
> it's likely to break at runtime.
Le 27/10/2014 16:07, Hilko Bengen a écrit :
> 1. Testing whether a rebuild against the newer version still works is
> clearly not sufficient: code can be loaded at run-time, for instance.
True, but that's more the exception than the rule, and I don't think
many projects load Guava classes dynamic
Package: wnpp
Owner: Hilko Bengen
Severity: wishlist
* Package name: guava-libraries-18
Version : 18.0
Upstream Author : Google Inc
* URL or Web page : http://code.google.com/p/guava-libraries/
* License : Apache-2.0
Description : Google Core Libraries for Java
##
10 matches
Mail list logo