On 02/27/2015 06:16 PM, Paul Sandoz wrote: > On Feb 27, 2015, at 4:47 PM, Florian Weimer <fwei...@redhat.com> wrote: >> I really don't think this tooling support will provide sufficient >> enticement to developers to maintain separate 7/8/9 source branches of >> their libraries. Isn't that the main obstacle, and not the way the bits >> are delivered? >> > > What if all the source for 7/8/9 bits were under one project?
Tool support for that is still worse than for separate branches of the same project. In general, VCS support for branches is still quite poor because the sensible thing to do is to develop a feature on the master branch and then backport it to older release branches as needed. But such selective backwards-merging very much lacks VCS support because the least common ancestor logic build into almost all current tools does not apply in this scenario. From a tool perspective, developing the feature in the oldest relevant release and then merging forward is the only supported way. But it's usually bad engineering because you want new features to use current facilities of the code base. So the only thing you have left is to cherry-pick individual patches (I think thats what “hg transplant” does in Mercurial). Anyway, you lose the tiny bit of tool support you have for backporting if you have everything in the same source repository. > For example, say there is a source file: > > src/main/java/foo/Foo.java > > whose content is: > > import sun.misc.BASE64Decoder; > > public class Foo { > // does something with sun.misc.BASE64Decoder > } > > There might be another source file located in the 8 area that overrides that > in the unversioned area: > > src/main-8/java/foo/Foo.java > > whose content is: > > import java.util.Base64; > > public class Foo { > // does something equivalent with java.util.Base64 > } This really screams preprocessor. :-( > The public contract of Foo should remain identical across the major Java > platform dependent versions, in a more strict sense the public signatures in > the byte code should be identical (the jar tool has been modified to check > this). If that's the goal, something like Retroweaver seems far more appropriate than forcing library authors to maintain separate sources. Multi-version JAR files seem useful because they will eventually allow evolution of the class file format. But I think the current use case isn't really there, I'm afraid. -- Florian Weimer / Red Hat Product Security