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 #203: API Work - Stabilization
Date Wed, 26 Apr 2017 06:55:44 GMT
Github user NightOwl888 commented on the issue:

    https://github.com/apache/lucenenet/pull/203
  
    @davhdavh 
    
    > 1. The assemblies are not strong-named in either debug or release build.
    
    Per Itamar (the project manager), [Lucene.Net will not be strong-named going forward](http://code972.com/blog/2014/04/68-ditching-strong-naming-for-lucene-net).
I don't agree with all of his points, but for now I am just going to see how many people complain.
I did strong-name the [`spatial4n` dependency](https://github.com/NightOwl888/Spatial4n/)
just in case we need to do it. He might be right that it is time to ditch it as some other
open-source projects have. Personally, I don't need it - do you? If so, I suggest you complain
loudly about it on the [dev mailing list](https://cwiki.apache.org/confluence/display/LUCENENET/Mailing+Lists)
and open an issue on [JIRA](https://issues.apache.org/jira/browse/LUCENENET-574?jql=project%20%3D%20LUCENENET%20AND%20status%20%3D%20Open)
about it so we can see how many votes it gets.
    
    > 2. The assembly version is 4.0.0.0. I believe the right thing to do would be to set
[assembly: AssemblyVersion("4.8.*")] and [assembly: AssemblyInformationalVersion("4.8-apiwork-ci")]
    
    In case we do strong-name because of popular demand, setting the assembly version to 4.0.0.0
is the right way to go. This is what the MVC team did - all versions of MVC 4 were 4.0.0.0
(until a they found a security vulnerability so severe that they had to force everyone to
upgrade to it, then it incremented to 4.0.0.1). If you read the [SemVer](http://semver.org/)
document, the behavior of strong-naming acts exactly like changing the major version, since
whenever it is changed it breaks binary compatibility. Therefore, it should never change unless
the major version is changed.
    
    > After trying to get strong names on, I can say that the entire build system is broken
on latest version of dotnet sdk. 1. Restore needs a specific sln, since there are two, ie:
& dotnet.exe restore $base_directory\Lucene.Net.sln 2. build command no longer accepts
a project.json, but instead uses the csproj files.
    
    If you look at the [`global.json` file](https://github.com/apache/lucenenet/blob/master/global.json),
the build requires the `1.0.0-preview2-1-003177` SDK, which is the [current one](https://github.com/dotnet/core/blob/master/release-notes/download-archive.md)
that supports `project.json` (but now that you mention it, the README needs to state the prerequisites).
The `global.json` file ensures the right SDK is used even if a newer one is installed.
    
    I made an attempt to unify to one solution and upgrade to `.csproj`, but ran into many
issues:
    
    1. The NUnit test adapter doesn't yet support `.csproj` on .NET Core, so no debugging
in VS2017 on .NET Core unless you fire off the tests manually or with NUnitLite.
    2. Some of the tests would not complete after the switch.
    3. With `.csproj`, versioning is still broken with respect to what I mentioned above about
the assembly version (which I plan to file an issue about) - when you specify an AssemblyVersion,
it always uses the same version for the AssemblyFileVersion, meaning they cannot differ. Also,
it is broken in respect to using a non SemVer scheme (which I don't see an alternative for
a port, since we will almost certainly have multiple production releases that correspond to
Lucene 4.8.0). You cannot pass a version number to the `dotnet pack` command, only a version
suffix (which always assumes there will be a `-` before it and always assumes there will be
a version prefix). In addition, when generating the NuGet packages for a pre-release, it doesn't
update the project dependency version numbers to pre-release (which gives you compile warnings).
    
    These issues can probably be overcome and I much prefer the new format, but I didn't want
to delay the release any longer. I think it would be best to wait until Microsoft announces
they are feature-complete  and NUnit Test Adapter has .NET Core support rather than trading
one broken build system for another.
    
    I wouldn't object if you want to contribute a build option to turn on strong-naming (provided
it doesn't break the build in TeamCity). But keep in mind, many of the assemblies are using
`InternalsVisibleTo` so we will need a conditional compilation symbol (`FEATURE_STRONGNAME`)
to toggle them between the standard and strong-named form. The strong-name option would not
necessarily need to extend to the `Lucene.Net.sln` solution or its projects, since they are
not used for the build.


---
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