lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: [VOTE] Removing strong naming from all future versions
Date Sat, 17 May 2014 20:53:59 GMT
To clarify, I realize that is the problem trying to be solved, it's just
that we lose all versioning by default in our NuGet package, including
against major versions, which is concerning when it comes to large projects
with a spider web of dependency.

I was thinking something closer along the lines of what Json.Net did: (
http://james.newtonking.com/archive/2012/04/04/json-net-strong-naming-and-assembly-version-numbers).
Increasing the assembly version number only when a major release happens is
the same thing that ASP.Net MVC and the .NET runtime do.  .NET 4.5 has the
same version numbers as .NET 4.0, etc.

It's just personal preference, really, because it's almost inevitable that
you are going to have assembly versioning issues with either solution in
large projects, it will either happen at runtime or compile time.  Signing
happens to be more fragile, and unsigned assemblies happens to 'just-work'
in more cases.  When assemblies remove deprecated methods, however, you
start to get fun runtime errors, like MethodMissingException when types are
loaded.


On Sat, May 17, 2014 at 12:59 PM, Christopher Currens <
currens.chris@gmail.com> wrote:

> I feel like it's worthwhile to mention that Strong Naming the assembly is
> how an assembly gets it's identity.
>
> Take for example the following assemblies:
>
> -- Lucene.Net version 3.0.0.0
> -- Lucene.Net version 3.0.3.0
> -- Lucene.Net version 4.0.0.0
>
> If I added a reference to Lucene.Net 4.0 to my application, ANY of those
> assemblies would match, as far as the runtime is concerned if the
> assemblies are unsigned. The strong name of an assembly is the
> _combination_ of the simple text name, version, culture and public key, not
> simply the public key. Without strong naming, you do NOT get real assembly
> versioning.
>
> See here for a reference:
> http://msdn.microsoft.com/en-us/library/51ket42z(v=vs.110).aspx
>
> >> The runtime distinguishes between regular and strong-named assemblies
> for the purposes of versioning. Version checking only occurs with
> strong-named assemblies.
>
> I would prefer to leave the strong-named option in nuget, and allow users
> to manually download an unsigned binary, if they choose to. However, the
> vote is over and already decided, so it's probably a moot point.
>
>
> On Sat, May 3, 2014 at 10:48 AM, Itamar Syn-Hershko <itamar@code972.com>wrote:
>
>> Vote concluded, we will remove strong naming this week.
>>
>> --
>>
>> Itamar Syn-Hershko
>> http://code972.com | @synhershko <https://twitter.com/synhershko>
>> Freelance Developer & Consultant
>> Author of RavenDB in Action <http://manning.com/synhershko/>
>>
>>
>> On Thu, May 1, 2014 at 10:20 PM, Itamar Syn-Hershko <itamar@code972.com
>> >wrote:
>>
>> > Michael, this is a majority vote, and this is what I was implying, sorry
>> > if it was understood differently. Also, vetoing isn't on by default on
>> all
>> > votes, like you can read in the link you provided.
>> >
>> > Either way, you haven't provided your vote.
>> >
>> > --
>> >
>> > Itamar Syn-Hershko
>> > http://code972.com | @synhershko <https://twitter.com/synhershko>
>> >
>> > Freelance Developer & Consultant
>> > Author of RavenDB in Action <http://manning.com/synhershko/>
>> >
>> >
>> > On Thu, May 1, 2014 at 8:46 PM, michael herndon <
>> > mherndon@michaelherndon.com> wrote:
>> >
>> >> Its probably worth reiterating that with this vote:
>> >>
>> >> Signed binaries are NOT going away.
>> >>
>> >>   - They are just reverting back to the previous manual download
>> >> distribution method.
>> >>   - Nothing prevents a developer from creating their own nuget feed
>> with
>> >> the signed binaries using something like nuget.server or myget.org.
>> >>
>> >> On a side note, statements like, "Michael and Simon's votes are still
>> >> absent but that won't matter anyway.", should be avoided in the future.
>> >>
>> >> The above statement could be misconstrued as:
>> >>
>> >> a) Voting doesn't matter and thus a person's opinion or voice doesn't
>> >> matter. Part of purpose of voting is to elicit feedback and
>> >> build consensus with the community because the community matters. The
>> >> other
>> >> purpose is conflict resolution.
>> >>
>> >> b) That the named parties are the only missing committer votes. There
>> are
>> >> other members not listed that have not voted.
>> >>
>> >> b) That people are being singled out. Calling out people rather than
>> just
>> >> focusing on the issue is bad form. It can make things seem personal or
>> >> meant for public shaming even when the intent was anything but that.
>> >>
>> >> c) Majority rules applies to this vote when it does not.  A single
>> binding
>> >> negative one vote effectively vetoes a code modification vote /
>> proposal
>> >> like this one.  https://www.apache.org/foundation/voting.html
>> >>
>> >> -M
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Thu, May 1, 2014 at 8:57 AM, Simon Svensson <sisve@devhost.se>
>> wrote:
>> >>
>> >> > +1
>> >> >
>> >> > (I'll admit that I had no idea that I had any voting power...)
>> >> >
>> >> >
>> >> > On 01/05/14 14:33, Itamar Syn-Hershko wrote:
>> >> >
>> >> >> Ok so we have 4 binding votes in favor to this move (counting Paul
>> as
>> >> well
>> >> >> because of his recent contributions), 1 non-binding in favor, and
2
>> >> >> non-binding against it.
>> >> >>
>> >> >> Michael and Simon's votes are still absent but that won't matter
>> >> anyway.
>> >> >>
>> >> >> I haven't announced a deadline initially so I'll be setting one
now.
>> >> Vote
>> >> >> terminates May 2nd 2PM GMT, just a bit over 24h from now.
>> >> >>
>> >> >> We will then move to making the mentioned changes.
>> >> >>
>> >> >> --
>> >> >>
>> >> >> Itamar Syn-Hershko
>> >> >> http://code972.com | @synhershko <https://twitter.com/synhershko>
>> >> >> Freelance Developer & Consultant
>> >> >> Author of RavenDB in Action <http://manning.com/synhershko/>
>> >> >>
>> >> >>
>> >> >> On Thu, May 1, 2014 at 1:39 AM, Nicholas Paldino <
>> >> >> casperOne@caspershouse.com
>> >> >>
>> >> >>> wrote:
>> >> >>> +1
>> >> >>>
>> >> >>>  On Apr 30, 2014, at 6:38 PM, "Troy Howard" <thoward37@gmail.com>
>> >> wrote:
>> >> >>>>
>> >> >>>> +1
>> >> >>>>
>> >> >>>> On Tue, Apr 29, 2014 at 9:49 AM, Prescott Nasser <
>> >> geobmx540@hotmail.com
>> >> >>>> wrote:
>> >> >>>>
>> >> >>>>  +1 since we will make both available
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> -----Original Message-----
>> >> >>>>> From: "Paul Irwin" <pirwin@feature23.com>
>> >> >>>>> Sent: ‎4/‎29/‎2014 7:06 AM
>> >> >>>>> To: "dev@lucenenet.apache.org" <dev@lucenenet.apache.org>
>> >> >>>>> Subject: Re: [VOTE] Removing strong naming from all
future
>> versions
>> >> >>>>>
>> >> >>>>> +1 since an alternative signed version would be available
as a
>> >> >>>>> download.
>> >> >>>>>
>> >> >>>>>
>> >> >>>>> On Tue, Apr 29, 2014 at 9:20 AM, Itamar Syn-Hershko
<
>> >> >>>>> itamar@code972.com
>> >> >>>>>
>> >> >>>>>> wrote:
>> >> >>>>>> Here is my +1
>> >> >>>>>>
>> >> >>>>>> All reasoning are here:
>> >> >>>>>>
>> >> >>>>>>  http://code972.com/blog/2014/04/68-ditching-strong-naming-
>> >> >>> for-lucene-net
>> >> >>>
>> >> >>>> We will publish both signed and non-signed. If someone
can't
>> change
>> >> >>>>>>
>> >> >>>>> their
>> >> >>>
>> >> >>>> process for making their project not sign, they are most
likely
>> not
>> >> >>>>>>
>> >> >>>>> using
>> >> >>>
>> >> >>>> nuget anyway. May be a bit harsh but that's mostly true.
>> >> >>>>>>
>> >> >>>>>> --
>> >> >>>>>>
>> >> >>>>>> Itamar Syn-Hershko
>> >> >>>>>> http://code972.com | @synhershko <
>> https://twitter.com/synhershko>
>> >> >>>>>> Freelance Developer & Consultant
>> >> >>>>>> Author of RavenDB in Action <http://manning.com/synhershko/>
>> >> >>>>>>
>> >> >>>>>>
>> >> >>>>>> On Tue, Apr 29, 2014 at 11:29 AM, 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/>
>> >> >>>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>
>> >> >>>>> --
>> >> >>>>>
>> >> >>>>> Paul Irwin
>> >> >>>>> Lead Software Engineer
>> >> >>>>> feature[23]
>> >> >>>>>
>> >> >>>>> Email: pirwin@feature23.com
>> >> >>>>> Cell: 863-698-9294
>> >> >>>>>
>> >> >>>>>
>> >> >
>> >>
>> >
>> >
>>
>
>

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