Big OK from our end
Sorry to be nagging on this again, but it would be very nice if you could
incorporate https://issues.apache.org/jira/browse/LUCENENET-431 in 2.9.4 as
well. It is one of those bugfixes that really fix a lot more than they can
possible break, so I hope this will justify a small d
>
> We should probably fix the ClsCompliance warnings if they have not already
> been fixed
We will have some issues with this - some are marked volatile - which basically
have to be a non-CLS compliant type (as far as my research is finding) Anyone
have thoughts? I went through and repl
We're taking a quick poll over the next few days to see how people would
like use Lucene.Net through Nuget on the developers mailing list**
Currently version 2.9.2 is hosted on nuget.org, but that package was not
create by the project maintainers, thus nuget is not currently set up in
source. Goi
> Right now there are two packages: Lucene & Lucene.Contrib. My question to
> the community is do you wish to finer grain packages, i.e. a package for
> each contrib project or continue to keep it simple.
>
+1 Granular, we just need to be good about descriptions.
>
> Another topic to converse
I'm going to vote +1 for granular.
With the RC you could look at myget and have a Lucene.Net repository on there
so people can go for unstable on myget, stables on nuget.
Also, I came across this article which explains how to setup a build server to
automatically push to nuget/ myget which coul
>We have a folder /trunk/docs, shouldn't this be the place for that?
We should have a live site for the documentation that people can browse,
similar to the parent project's site.
http://lucene.apache.org/java/3_4_0/api/all/index.html. It makes it the
documentation more accessible.
The rub is tha
While it may be a bit redundant, why couldn't there be an individual
package for each piece of contrib and a "Lucene.Net Contrib (All)"
package that drags them all down.
That way users can grab just the bit they need, or if they just want
to get the whole thing, grab the "All" package.
Thanks,
Tr
On Wed, Sep 21, 2011 at 12:31 AM, Troy Howard wrote:
> While it may be a bit redundant, why couldn't there be an individual
> package for each piece of contrib and a "Lucene.Net Contrib (All)"
> package that drags them all down.
>
> That way users can grab just the bit they need, or if they just
At one time I had a SVN server set up at work that had a post-commit
hook set up that would generate a static HTML site from the XML doc
files using Sandcastle. So.. It can be done. That was about 3-4 years
ago and I don't work at that company any longer, so I don't have
access to the details of ho
Could we store sandcastle docs as a single zip/chm?
On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard wrote:
> At one time I had a SVN server set up at work that had a post-commit
> hook set up that would generate a static HTML site from the XML doc
> files using Sandcastle. So.. It can be done. T
Why would we want to do that?
Under the /site/docs directory, they need to be served up as loose HTML...
IMO the XML files shouldn't be checked into SVN because they are
auto-generated. The same goes for Sandcastle files.. However, in the
release packages, I think we should include the XML files
I'm with you on checking in the static files into ~/site/doc/version
that would be pretty easy to automate from jenkins & msbuild if we can get
the docs into static html.
I currently just push all assemblies, help files, xml docs into ~/trunk/bin
on the user's local once the scripts finish build
12 matches
Mail list logo
