lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From NightOwl888 <...@git.apache.org>
Subject [GitHub] lucenenet issue #191: Migrating Lucene.Net to .NET Core
Date Sun, 13 Nov 2016 16:48:04 GMT
Github user NightOwl888 commented on the issue:

    https://github.com/apache/lucenenet/pull/191
  
    > @NightOwl888 @synhershko I am looking through the PR and reducing any unnecessary
changes. To make this PR smaller, I was wondering if it would be a good idea to split my changes
from NUnit 2 -> NUnit 3 into another PR? (dotnet-test-nunit uses NUnit3)
    
    @conniey, thanks for putting all of the effort into this.
    
    It would be very helpful if you would outline what the plan is to get from this branch
to building both .NET 4.5.1 and .NET Core for NuGet release. For the time being, lets not
focus so much on the tools (such as TeamCity or which scripting language to use), but on the
packaging and deployment requirements for NuGet.
    
    In my mind it seems like it would be best to first get everything onto one branch (preferably
master), since a build script that uses 2 different branches would be hard to maintain, and
the remaining code changes we need to do for release will definitely be harder to maintain
on multiple branches. Do you agree? If so, what needs to happen (if anything) to get this
branch (and/or #194) ready to merge? If not, please provide some info.
    
    Is it going to be easier to put binaries for both .NET 4.5.1 and  .NET Core into the same
NuGet package, or do we need separate packages? Will it be possible to put both the 32 and
64 bit binaries into the same NuGet package? I think we should aim for as few packages as
possible (preferably a single NuGet package per project that contains binaries for all platforms
and bitness), which is generally easier to maintain than separate packages.
    
    Let's assume that everyone who wants to use Lucene.Net on .NET Core will download it via
NuGet. What needs to happen to get us to that point? Specifically, are there any special requirements
necessary to get the icu-dotnet dependency into the target project? Is icu-dotnet ready to
be deployed via NuGet now, or does something else need to be finished and/or automated first?
Are there any known restrictions to the type of projects/platforms that it can be deployed
into? Are there any additional special requirements that we need to take into consideration
that vary from a "normal" .NET Core NuGet deployment?
    
    Are you interested in making a build script (or at least the start of one) to not just
build and test both .NET frameworks, but also to package them up via NuGet, and perhaps make
`install.ps1`/`uninstall.ps1` scripts for delivery (assuming we are going to put both 32 bit
and 64 bit in the same package), or should we leave that task to Wyatt and/or me? A common
approach that is compatible with any CI server is just to make a script that drops the build
artifacts into a `.gitignore`d local directory. The CI server (whether it is TeamCity or MyGet)
can then be configured to pick up the .nuget artifacts and put them into a MyGet feed. When
we are satisfied that we have reached the appropriate release point, we can then manually
push from MyGet to NuGet. From Wyatt's description, that is similar to the setup we have now,
we just need the build script that is smart enough to do the packaging that can be plugged
into the TeamCity setup.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message