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 [email protected] or file a JIRA ticket
with INFRA.
---
