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 <[email protected]> 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:[email protected]] > Sent: Saturday, November 12, 2016 12:34 AM > To: [email protected] > 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 <[email protected]> > 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 > > <[email protected]> > > 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 > > > <[email protected]> > > > 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:[email protected]] > > > Sent: Saturday, October 22, 2016 1:03 PM > > > To: [email protected] > > > Subject: nuget.org and 4.8 > > > > > > Do we want to have the packages pushed to nugget as pre-release? > > > > > >
