Alexey Shcherbachev points seems reasonable to me. We should not add barriers to acceptance of the project.
Maybe this could be useful. I created a new console project in VS2012 (so that is not signed) and added some nuget packages from top of the nuget list. Seems like that list is ordered by popularity. Then I removed EntityFramework.*, System.* and Microsoft.* because - of course they are signed, they are from MS. So this is current state of affairs, but maybe Lucene.NET community want's to lead to a better world.... Autofac, Version=3.3.0.0, Culture=neutral, PublicKeyToken=17863af14b0044da AutoMapper, Version=3.2.0.0, Culture=neutral, PublicKeyToken=be96cd2c38ef1005 AutoMapper.Net4, Version=3.2.0.0, Culture=neutral, PublicKeyToken=be96cd2c38ef1005 AWSSDK, Version=2.0.13.3, Culture=neutral, PublicKeyToken=9f476d3089b52be3 Castle.Core, Version=3.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc Castle.Windsor, Version=3.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc Common.Logging, Version=2.1.2.0, Culture=neutral, PublicKeyToken=af08829b84f0328e Dapper, Version=1.12.1.1, Culture=neutral, PublicKeyToken=null Elmah, Version=1.2.14706.0, Culture=neutral, PublicKeyToken=null FakeItEasy, Version=1.19.0.0, Culture=neutral, PublicKeyToken=eff28e2146d5fd2c FluentAssertions, Version=2.2.0.0, Culture=neutral, PublicKeyToken=33f2691a05b67b6a FluentNHibernate, Version=1.4.0.0, Culture=neutral, PublicKeyToken=8aa435e3cb308880 FluentValidation, Version=5.1.0.0, Culture=neutral, PublicKeyToken=null ICSharpCode.SharpZipLib, Version=0.86.0.518, Culture=neutral, PublicKeyToken=1b03e6acf1164f73 Iesi.Collections, Version=1.0.1.0, Culture=neutral, PublicKeyToken=aa95f207798dfdb4 Ionic.Zip, Version=1.9.2.0, Culture=neutral, PublicKeyToken=null log4net, Version=1.2.13.0, Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a MongoDB.Bson, Version=1.9.0.200, Culture=neutral, PublicKeyToken=f686731cfb9cc103 MongoDB.Driver, Version=1.9.0.200, Culture=neutral, PublicKeyToken=f686731cfb9cc103 Moq, Version=4.2.1402.2112, Culture=neutral, PublicKeyToken=69f491c39445e920 MySql.Data, Version=6.8.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d MySql.Data.Entity.EF6, Version=6.8.3.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d Newtonsoft.Json, Version=6.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed NHibernate, Version=3.3.1.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4 Ninject, Version=3.2.0.0, Culture=neutral, PublicKeyToken=c7192dc5380945e7 NLog, Version=2.1.0.0, Culture=neutral, PublicKeyToken=5120e14c03d0593c Owin, Version=1.0.0.0, Culture=neutral, PublicKeyToken=f0ebd12fd5e55cc5 Quartz, Version=2.2.3.400, Culture=neutral, PublicKeyToken=f6b8c98a402cc8a4 RestSharp, Version=104.4.0.0, Culture=neutral, PublicKeyToken=null Rhino.Mocks, Version=3.6.0.0, Culture=neutral, PublicKeyToken=0b3305902db7183f StructureMap, Version=3.0.2.0, Culture=neutral, PublicKeyToken=null StructureMap.Net4, Version=3.0.2.0, Culture=neutral, PublicKeyToken=null TechTalk.SpecFlow, Version=1.9.0.77, Culture=neutral, PublicKeyToken=0778194805d6db41 WebActivatorEx, Version=2.0.0.0, Culture=neutral, PublicKeyToken=7b26dc2a43f6a0d4 xunit, Version=1.9.2.1705, Culture=neutral, PublicKeyToken=8d05b1bb7a6fdb6c Regards, Petar On Tue, Apr 29, 2014 at 11:37 AM, Alexey Shcherbachev < [email protected]> wrote: > -1 > > I am not a Lucene.Net committer, but just in case community votes are > considered too, I would strongly opt to keep Lucene.Net signed by default. > Motivation is that keeping assemblies references by Lucene.net signed > requires fewer work than forcing everybody (who needs signed version) to > use alternative distribution or sign it themselves. > > Regards, > Alexey Shcherbachev > > > On Tue, Apr 29, 2014 at 12:29 PM, Rob Vesse <[email protected]> wrote: > > > -1 > > > > I am strongly in favour of keeping strong naming for previously mentioned > > reasons, I believe removing the signing will cause issues throughout the > > wider ecosystem of developers who rely on Lucene.Net > > > > Counter-proposal: > > > > Publish both signed and unsigned packages and leave it up to users to > > decide which to use, the main package IDs should continue to be signed > and > > new package IDs should be created for the unsigned variants > > > > Rob > > > > On 29/04/2014 03:52, "Itamar Syn-Hershko" <[email protected]> wrote: > > > > >This is a vote for removing strong naming from Lucene.NET effective > > >immediately, affecting all future versions including the planned v3 > bugfix > > >release and obviously the v4 branch, arguments being: > > > > > >1. This is a headache to manage, given dependencies may or may not be > > >signed and as long as we are signed we can't use them without signing > them > > >first. At this point in time it's a blocker for us from releasing the v3 > > >bugfix version. > > > > > >2. Strong naming is pretty much pointless as it is anyway, especially > > >since > > >we are OSS and our key is public anyway. > > > > > >All main distribution channels (nuget, binary downloads) will not be > > >signed, but we will provide a download link with a signed version for > > >people who need a signed. This is to address needs coming from people > who > > >already have signed their projects. > > > > > >We will also publish a Wiki page describing this move in detail, with > the > > >hopes people will remove signing from their projects instead of using > the > > >signed version. > > > > > >Let's make the world a better place. > > > > > >-- > > > > > >Itamar Syn-Hershko > > >http://code972.com | @synhershko <https://twitter.com/synhershko> > > >Freelance Developer & Consultant > > >Author of RavenDB in Action <http://manning.com/synhershko/> > > > > > > > > > > >
