Assuming we're talking about the packaging/filesystem structure in the releases, the structure is a little of both (ours vs Apache's)... Basically, I went through most of the Apache projects to see how they packaged releases and developed a structure that was very similar but encompassed everything we needed. So, it's informed by the organically emergent structures that ASF uses.
-T On Mon, Jun 25, 2012 at 7:32 AM, Prescott Nasser <geobmx...@hotmail.com> wrote: > > I have no idea why I thought we were using Nant. > I think it's just "our release structure". I figured a little out this > weekend, splitting the XML and .dll files into separate directories. The > documentation you have on the wiki was actually pretty helpful. > Whatever more you can add would be great > > ~P > >> Date: Mon, 25 Jun 2012 10:04:21 -0400 >> Subject: Re: Outstanding issues for 3.0.3 >> From: mhern...@wickedsoftware.net >> To: lucene-net-dev@lucene.apache.org >> >> On Sat, Jun 23, 2012 at 1:38 AM, Prescott Nasser >> <geobmx...@hotmail.com>wrote: >> >> > >> > >> > > -- Task 470, a non-serious one, is listed only because it's mostly done >> > and >> > > just need a few loose ends tied up. I'll hopefully have time to take care >> > > of that this weekend. >> > >> > >> > How many GetX/SetX are left? I did a quick search for 'public * Get*()' >> > Most of them looked to be actual methods - perhaps a few to replace >> > >> > >> > > -- Task 446 (CLS Compliance), is important, but there's no way we can get >> > > this done quickly. The current state of this issue is that all of the >> > > names of public members are now compliant. There are a few things that >> > > aren't, the use of sbyte (particularly those related to the FieldCache) >> > and >> > > some conflicts with *protected or internal* fields (some with public >> > > members). Opinions on this one will be appreciated the most. My opinion >> > > is that we should draw a line on the amount of CLS compliance to have in >> > > this release, and push the rest into 3.5. >> > >> > >> > >> > I count roughly 53 CLS compliant issues. the sbyte stuff will run into >> > trouble when you do bit shifting (I ran into this issue when trying to do >> > this for 2.9.4. I'd like to see if we can't get rid of the easier stuff >> > (internal/protected stuff). I would not try getting rid of sbyte or >> > volatile for thile release. It's going to take some serious consideration >> > to get rid of those >> > >> > >> > > -- Improvement 337 - Are we going to add this code (not present in java) >> > to >> > > the core library? >> > >> > >> > >> > I'd skip it and re-evaluate the community desire for this in 3.5. >> > >> > >> > > -- Improvement 456 - This is related to builds being output in Apache's >> > > release format. Do we want to do this for this release? >> > > >> > >> > >> > I looked into this last weekend - I'm terrible with Nant, so I didn't get >> > anywhere. It would be nice to have, but I don't think I'll figure it out. >> > If Michael has some time to maybe make the adjustment, he knows these >> > scripts best. If not I'm going to look into it, but I don't call this a >> > show stopper - either we have it or we don't when the rest is done. >> > >> >> With some Flo Rida and expresso shots, anything is possible. >> >> Did we switch to Nant? >> >> I saw the jira ticket for this. Is there an official apache release >> structure or this just our* apache release structure that we are using? >> Can I take the latest release and use that to model the structure you guys >> want? >> >> @Prescott declarative xml build scripts are a pita in general. only reason >> we're using this over powershell or a scripting language is that mono >> supports it and most .NET devs have it already installed. >> >> I'll spend some more time documenting it so that others can work on it and >> even refactor it. >> >> > >> > >> > >> > >> > >> > ~P >
