lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Itamar Syn-Hershko <ita...@code972.com>
Subject Re: nuget.org and 4.8
Date Sat, 12 Nov 2016 21:20:47 GMT
Wyatt - Patch version increments are perfect. You seem to indicate there
will be an issue with that but I'm not sure which?

I think the nuget account is registered on me. Feel free to do the research
and let me know what you need me to do there. I can get you an API key if
that would work.

As far as building goes, you have FAKE and Psake for .NET - I think we
should probably stick to those, but I'd defer this to Wyatt, Connie and
Shad as you are obviously more versed in this process than me at this point.

--

Itamar Syn-Hershko
http://code972.com | @synhershko <https://twitter.com/synhershko>
Freelance Developer & Consultant
Lucene.NET committer and PMC member

On Sat, Nov 12, 2016 at 2:55 PM, Shad Storhaug <shad@shadstorhaug.com>
wrote:

> > Do we have a sense of how many folks are using it?
>
> Not a lot - you can get a rough idea about how many by the number of
> downloads of the package: https://myget.org/feed/lucene-
> net/package/nuget/Lucene.Net.
>
> On the other hand, on NuGet we are getting an average of 614 downloads per
> day, so we can expect the number to grow quite a bit from where it is when
> we get the pre-release up there. Based on other pre-releases I have dealt
> with, I would guess that will put the number of downloads around 30-50 per
> day, but it could be higher depending on how much buzz there is around
> Lucene.Net and how many people seek out the new feature set.
>
> But in any case it certainly makes more sense to break any versioning
> scheme now before we get on NuGet than after. It might help to setup a test
> MyGet feed and play with some fake NuGet packages (they are just Zip files
> with a different extension and a pre-defined folder structure) and Visual
> Studio with the current versioning scheme to determine if upgrading will
> work correctly as-is. It seems like it should work as-is, but it would be
> nice to have proof.
>
> ----------------------------------------
>
> > Regarding Nuget pushes -- do we have the credentials to the account that
> "owns" the package?
>
> It may not be necessary to have the credentials. What is necessary is for
> MyGet to be setup with an API key (which someone with credentials will need
> to obtain). If MyGet already has an API key, you can simply push the
> package upstream to NuGet via the MyGet control panel once it is ready.
>
> http://blog.myget.org/post/2012/06/06/Pushing-packages-
> from-MyGet-to-NuGet-(or-another-feed).aspx
>
> ----------------------------------------
>
> If you are following along with the exchange between Connie Yau and me,
> there is some new information that she has provided that helps with this
> effort.
>
> First of all, it looks like for the time being we are stuck with MSBuild.
> This most likely means that we need to have a build script in order to
> support the multi-targeting of .NET 4.5.1 and .NET Core and to package both
> into the same NuGet package.
>
> It sounds like we will need to have separate binaries for 32 bit and 64
> bit for the Lucene.Net.Analysis.Common package (correct me if I am wrong
> Connie). While NuGet does have multi-targeting support built-in for
> different .NET frameworks, it apparently doesn't have support built-in for
> different bitness: http://stackoverflow.com/a/8231107. What that most
> likely means is that we need to either split into separate 32 and 64 bit
> NuGet packages (yuck) or create a scripted alternative to check which
> bitness the target project is targeting and install the correct binary.
> There is an example of such an approach here: http://stackoverflow.com/a/
> 11376762.
>
> Whatever bitness solution we come up with for Lucene.Net.Analysis.Common
> will apply to Lucene.Net.Highlighter and Lucene.Net.Analysis.ICU as well.
>
> The most sensible thing to do at this point is to wait for a response from
> Connie to determine such things as:
>
> 1. Do we need to wait for #191 to be merged before starting on this?
> 2. How much time will it take for that to happen?
> 3. What, if any, scripts will need to be made for building, for NuGet
> packaging, and for NuGet package installation?
> 4. Can we take advantage of the new project.json functionality (
> https://docs.nuget.org/ndocs/schema/project.json) to specify what is in
> the NuGet packages, should we use the older XML .nuspec format, or some
> other method?
> 5. Which of the scripts will be prepared by Connie and her team, and which
> will need to be prepared by Wyatt, Presscott, or me?
> 6. Is switching to xUnit still the plan or are we sticking with NUnit?
> 7. If making scripts, what scripting tool(s) should be used?
>
> For the build scripts we should only be using cross-platform tools going
> forward.
>
> One option is Gulp, a node.js extension which has the (cool) capability of
> running multiple things in parallel, which means we could run both builds
> in parallel, test them both in parallel, and run all of the NuGet pack
> commands in parallel.
>
> It looks like PowerShell is now also cross-platform:
> https://blogs.msdn.microsoft.com/dotnet/2016/08/18/
> powershell-is-now-open-source-and-cross-platform/, so that is also an
> option. In the past, I have used it in conjunction with PSake for builds:
> https://github.com/psake/psake. Connie is also using PowerShell scripts,
> so that makes at least 2 of us that are familiar with this.
>
> Wyatt mentioned he likes FAKE, care to elaborate on its feature set?
>
>
> Thanks,
> Shad Storhaug (NightOwl888)
>
>
> -----Original Message-----
> From: Wyatt Barnett [mailto:wyatt.barnett@gmail.com]
> Sent: Saturday, November 12, 2016 12:34 AM
> To: dev@lucenenet.apache.org
> Cc: Prescott Nasser
> Subject: Re: nuget.org and 4.8
>
> Patch numbers will incriment the way the setup is laid out. We will need
> to shift to the myget stuff to prerelease and that might cause some pain.
> Do we have a sense of how many folks are using it?
>
> Regarding Nuget pushes -- do we have the credentials to the account that
> "owns" the package? I wasn't involved in pushing it last time so I'm not
> sure how it got there.
>
> I'll take a stab at fixing the package naming stuff over the weekend.
>
> On Thu, Nov 10, 2016 at 3:51 PM Itamar Syn-Hershko <itamar@code972.com>
> wrote:
>
> > >> Thanks for all the hard work getting the code ready enough to have
> > >> this
> > discussion.
> >
> > Indeed! happy times!
> >
> > I say we keep the nightly builds published on myget. We can promote
> > packages from myget to nuget with a click of a button. We can do this
> > now to have the latest bits out there on myget as a prerelease, and
> > then the next time we do this we make sure that patch number was
> incremented.
> >
> > Before we do that however, we need to update the author / owner name
> > of all packages and add a description, see how they look at
> > https://myget.org/gallery/lucene-net
> >
> > WDYT?
> >
> > --
> >
> > Itamar Syn-Hershko
> > http://code972.com | @synhershko <https://twitter.com/synhershko>
> > Freelance Developer & Consultant Lucene.NET committer and PMC member
> >
> > On Mon, Oct 31, 2016 at 7:51 PM, Wyatt Barnett
> > <wyatt.barnett@gmail.com>
> > wrote:
> >
> > > Good questions, here are my thoughts on some answers:
> > >
> > > I concur getting out on nuget probably makes sense at this point.
> > >
> > > Good point on version numbering. The way we are wired right now
> > everything
> > > descends from a specific source control build so, if release does
> > > not involve any source control changes, it could be the same build
> > > number. So 4.8.0.687-beta and 4.8.0.687 would be identical builds for
> us.
> > >
> > > It looks like the metadata is coming out of the AssemblyInfo.cs
> > > files in each project, we should be able to flesh that out a bit there.
> > >
> > > The way we push to myget is based on a nightly build -- whenever
> > > master
> > is
> > > updated it will pick up the changes, run all the tests and push the
> > > artifacts to nuget. We could just repoint this at nuget if we
> > > wanted. For non-beta releases I think that nuget pushes should
> > > certainly be a manual step.
> > >
> > > Currently all of the builds happen in our teamcity server at
> > > https://teamcity.jetbrains.com/project.html?projectId=
> > > LuceneNet&tab=projectOverview
> > > <https://teamcity.jetbrains.com>. We don't have much of a build
> > > script going on outside of that, but that is very scripted and
> repeatable.
> > >
> > > Thanks for all the hard work getting the code ready enough to have
> > > this discussion.
> > >
> > > On Sat, Oct 22, 2016 at 4:37 PM Shad Storhaug
> > > <shad@shadstorhaug.com>
> > > wrote:
> > >
> > > My vote is yes.
> > >
> > > 1. If we had a pre-release presence on NuGet, more people might be
> > > interested in helping out (or at least providing feedback).
> > > 2. I have an open source project that depends on Lucene.Net, and it
> > > would be easier to deal with for me (and I am sure other projects
> > > that depend
> > on
> > > Lucene.Net) if the pre-release were available on NuGet instead of
> > > having
> > to
> > > instruct everyone how to setup their IDE/CI build to access MyGet.
> > >
> > > VERSIONING
> > >
> > > I am not sure if we have the versioning setup the right way:
> > > http://www.xavierdecoster.com/semantic-versioning-auto-
> > > incremented-nuget-package-versions
> > >
> > > I don't think there is a way to make a pre-release (that acts like a
> > > pre-release) when we have a 4 segment version number. Has this
> > > versioning scheme been fully tested when transitioning from
> pre-release to release?
> > > And also does it work when upgrading from Lucene.Net 3.0.3 to the 4
> > segment
> > > pre-release? I suppose using 4 segments will work if we increment
> > > the revision number when making this transition, but it would be
> > > difficult to correlate a pre-release to a specific release (at least
> > > for a .NET
> > release
> > > - but if the intent was only to correlate it with Java Lucene
> > > versions while allowing for bug fixes I think we have done it).
> > >
> > > PACKAGES
> > >
> > > It looks as though several of the more recently ported packages
> > > (such as Lucene.Net.Join, Lucene.Net.Suggest, Lucene.Net.Misc,
> > > Lucene.Net.Memory,
> > > Lucene.Net.QueryParser) are not currently part of the build:
> > > https://www.myget.org/gallery/lucene-net
> > >
> > > Also, the packages that exist seem to be missing the metadata (such
> > > as descriptions).
> > >
> > > Is there some reason why we don't have a build script checked into
> > > the repository to manage these details?
> > >
> > > RELEASES
> > >
> > > It also might pay off to wait until I push my local branch. I have
> > > fixed the majority of the remaining bugs in Lucene.Net.Core already,
> > > so it
> > would
> > > be best to post the latest and greatest on NuGet rather than
> > > yesterday's build. I was doing a bit more debugging, but let me
> > > change gears for the moment and work on getting this to a stable point
> to push to master.
> > >
> > > We certainly wouldn't want every CI build up on NuGet, though. We
> > > need to be able to manually push at certain stable points.  What is
> the plan?
> > >
> > >
> > > Thanks,
> > > Shad Storhaug (NightOwl888)
> > >
> > >
> > > -----Original Message-----
> > > From: Prescott Nasser [mailto:geobmx540@hotmail.com]
> > > Sent: Saturday, October 22, 2016 1:03 PM
> > > To: dev@lucenenet.apache.org
> > > Subject: nuget.org and 4.8
> > >
> > > Do we want to have the packages pushed to nugget as pre-release?
> > >
> >
>

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