lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wyatt Barnett <wyatt.barn...@gmail.com>
Subject Re: nuget.org and 4.8
Date Fri, 11 Nov 2016 17:33:47 GMT
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