You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucenenet.apache.org by Wyatt Barnett <wy...@gmail.com> on 2016/11/01 02:51:35 UTC
Re: nuget.org and 4.8
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 <sh...@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?
Re: nuget.org and 4.8
Posted by Itamar Syn-Hershko <it...@code972.com>.
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 <sh...@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 <it...@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
> > <wy...@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
> > > <sh...@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?
> > >
> >
>
RE: nuget.org and 4.8
Posted by Prescott Nasser <ge...@hotmail.com>.
I own the packages and I think Simon shares that access, will look up what you need tonight to push to it
Sent from my Windows Phone
________________________________
From: Shad Storhaug<ma...@shadstorhaug.com>
Sent: 11/12/2016 4:55 AM
To: wyatt.barnett@gmail.com<ma...@gmail.com>; Connie Yau<ma...@microsoft.com>
Cc: Prescott Nasser<ma...@apps4rent.net>; dev@lucenenet.apache.org<ma...@lucenenet.apache.org>
Subject: RE: nuget.org and 4.8
> 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 <it...@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
> <wy...@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
> > <sh...@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?
> >
>
RE: nuget.org and 4.8
Posted by Shad Storhaug <sh...@shadstorhaug.com>.
> 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 <it...@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
> <wy...@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
> > <sh...@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?
> >
>
Re: nuget.org and 4.8
Posted by Wyatt Barnett <wy...@gmail.com>.
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 <it...@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 <wy...@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 <sh...@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?
> >
>
Re: nuget.org and 4.8
Posted by Itamar Syn-Hershko <it...@code972.com>.
>> 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 <wy...@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 <sh...@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?
>