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
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
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
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
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,
Troy
On Wed, Sep 21, 2011 at 12:31 AM, Troy Howard thowar...@gmail.com 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
Could we store sandcastle docs as a single zip/chm?
On Wed, Sep 21, 2011 at 12:37 AM, Troy Howard thowar...@gmail.com 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..
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
