lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Petar Repac <petar.re...@gmail.com>
Subject Re: [VOTE] Removing strong naming from all future versions
Date Tue, 29 Apr 2014 09:49:06 GMT
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 <
alexey@renaissance-it.ru> 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 <rvesse@dotnetrdf.org> 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" <itamar@code972.com> 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/>
> >
> >
> >
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message