>> 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? >
