Many old builds will also have problems even with a git checkout. If you
actually wanted to try and build them it would be much more sane to work
from the SVN history I'd hope we can retain.

Mark

On Fri, Dec 4, 2015 at 4:55 PM Robert Muir <rcm...@gmail.com> wrote:

> On Fri, Dec 4, 2015 at 4:25 PM, Dawid Weiss <dawid.we...@gmail.com> wrote:
> >> I don't think jar files are 'history' and it was a mistake we had so
> >> many in source control before we cleaned that up. it is much better
> >> without them.
> >
> > Depends how you look at it. If your goal is to be able to actually
> > build ancient versions then dropping those JARs is going to be a real
> > pain. I think they should stay. Like I said, git is smart enough to
> > omit objects that aren't referenced from the cloned branch. The
> > conversion from SVN would have to be smart, but it's all doable.
>
> I mentioned this same issue the last thread where we discussed that, I
> do recommend to try to actually compile these old versions.
>
> As an experiment, I checked out the release tag for 4.2
> (http://svn.apache.org/repos/asf/lucene/dev/tags/lucene_solr_4_2_0)
> and ran 'ant compile'
>
> BUILD FAILED
> /home/rmuir/lucene_solr_4_2_0/build.xml:107: The following error
> occurred while executing this line:
> /home/rmuir/lucene_solr_4_2_0/lucene/common-build.xml:656: The
> following error occurred while executing this line:
> /home/rmuir/lucene_solr_4_2_0/lucene/common-build.xml:479: The
> following error occurred while executing this line:
> /home/rmuir/lucene_solr_4_2_0/lucene/common-build.xml:1578: Class not
> found: javac1.8
>
> That release was only 2 years ago, and its not the only problem you
> will hit. Besides build issues and stuff, I know at least Solr had a
> wildcard import, conflicting with the newly introduced
> java.util.Base64 that will prevent its compile. And I feel like there
> have been numerous sneaky generics issues that only Uwe seems to
> understand.
>
> Being able to build the old versions would require a good effort just
> to figure out what build tools / compiler versions you need to do it
> for the different timeframes, and git hashes aren't great if you want
> to document that or try to make some fancy bisection tool.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
- Mark
about.me/markrmiller

Reply via email to