Sorry again if this is not the right thread, but what feature of .Net 4.0 do you currently leverage that wouldn't compile on 3.5? (which would be fine for us) Troy, can we really compare the impact of moving Lucene development to vs2010 to that of moving the user base to .Net 4.0 ? Again, keep in mind that the best part of Lucene.Net libraries currently running are probably still 2.4.1, and IMHO trying to get a good part of those versions back up to date is not just a side option: enforcing .Net 4.0 was clearly a deal breaker for us so far, and reporting critical hints on 2.9.x obsolete constructs would be needed for those still behind, as I recall most of those comments were lost in the .Net port, and several pattern changes are just above your usual developer skills without the appropriate guidance. Of course it's up to the integrators to make the effort to adapt to the new API when needed, but there should be a practical path for that, or beware the Sharpmap syndrome, where only the same handful of developers kept moving ahead with no one behind to push when the initial energy burst slowly faded.
Anyway, thanks guys for making this live, and hopefully we can help at some point. Cheers, Jesse -----Message d'origine----- De : Simone Chiaretta [mailto:simone.chiare...@gmail.com] Envoyé : mercredi 1 février 2012 21:10 À : lucene-net-dev@lucene.apache.org Cc : lucene-net-dev@lucene.apache.org Objet : Re: [Lucene.Net] Graduation If I had to vote, I'd vote against graduation at this point. As other said, while the user base is pretty big, the dev community is relatively small and still relying on just a few people. Also all the accessories around a OSS projects are very difficult to maintain, probably due to the strict environment of the foundation, like CMS, CI, source control and so on. Also, there must be an official way of communicating to the user base, which is not the ML or some sporadic news on the site or on other blogs. But the main point is a lack of long term strategy that is shared by everyone: most OSS can go along without such things, but Lucene.net is in a position where such strategy is needed. Shall Lucene.net be just a port of the java lib, and evolving with it (and following the evolution of the java language) or shall it just be inspired by it and go along with the pace of .NET, which is much faster than the java one? Shall Lucene.net keep on actively supporting companies still on .NET 2.0, or follow the evolution and drop support of old versions and adopt the innovations coming with the newest releases? Personally I think Lucene.net should go directly to the latest version available of Lucene for java (which should have all the nice features like generics, lambda and such) and do as everybody is doing regarding support: just do critical bug fixes on older version and just support the latest or 2 latest versions of .NET (which now will be 4 and 3.5). But this is probably not the right thread to discuss this topics. Wrapping up, I'd say no to gradation until the strategy on these two points has been decided, and a better communication strategy is in place. Simone --- Simone Chiaretta @simonech Sent from a tablet On 01/feb/2012, at 20:37, Troy Howard <thowar...@gmail.com> wrote: > I agree with Neal on both points: > > - Repeatable, documented process: We need a better more defined, > public and repeatable process for creating and building releases. As > Prescott can attest to, figuring all that out at this point is > non-trivial and poorly documented. We have a wider footprint now than > ever before but we still have a long way to go in terms of solving our > problems as a team/community/project. > > - Committing to our decisions, despite alienating our user base: As > Jesse pointed out, there are users out there who will be alienated by > our choices, wether it be to use .Net 4.0 vs 2.0, use VS2010 vs > VS2008/2005, change the API to make more sense in .NET, or what have > you. We are going to have to make choices regarding the project > direction, commit to those choices and move forward, even if it does > mean alienating a certain portion of our user base. We don't like that > consequence but we can't survive as a project without being decisive > about controversial issues and moving forward. > > The question I have to Stephan is, what are the significant criteria > for moving a project from the Incubator to a TLP? > > In my mind, we have the "minimum marketable feature set" to be a TLP, > which is to say, we have an open dialog and an interested community > while remaining somewhat productive. I don't think we need to wait to > graduate until we have solved every challenge that we face as a > project but rather we simply need to prove that we have what it takes > to survive and grow in a healthy and productive manner as a community. > I think we've achieved that part and just need to continue improving > our process. > > Thanks, > Troy > > > On Wed, Feb 1, 2012 at 11:11 AM, Granroth, Neal V. > <neal.granr...@thermofisher.com> wrote: >> Jesse, >> >> Thanks for making that point. I am also in that situation where I must >> support.NET 2.0 for years into the future. While I can experiment with .NET >> 4.0, there are a number or reasons that preclude its deployment or anything >> that depends upon it. >> >> However, consider what the Lucene.NET developers are up against. I think I >> am not mistaken that the current version of Java, which the Lucene core >> project uses, now makes use of features that have no equivalent in .NET 2.0; >> use of the newer versions of .NET are essential in order to update >> Lucene.NET to the current version of Lucene. >> >> At some point you, I, and others in our situation have to develop >> migration plans to get our products (and customers) to upgrade to the >> newer versions of .NET >> >> - Neal >> >> -----Original Message----- >> From: Jean-Sylvain Boige [mailto:jsbo...@aricie.fr] >> Sent: Wednesday, February 01, 2012 12:44 PM >> To: lucene-net-dev@lucene.apache.org; >> lucene-net-...@incubator.apache.org >> Subject: RE: [Lucene.Net] Graduation >> >> Hi all, >> >> I'm not sure if it's the best moment for that, but here are my 2 cents. >> I have the feeling that a lot was done recently, and that the project >> is taking a good direction. >> >> To reflect on your impression, the one example of how it could go >> wrong I'm thinking of, where a few people invest in bursts and in >> their turn is Sharpmap (http://sharpmap.codeplex.com/) It's been >> years than a couple of committers are literally throwing thousands of >> lines of codes at that project, with dozens of branches and each >> method refactored a couple of time, but not a clean release since >> then, loads of inertia, and non committers quite at lost. >> >> I reckon the effort is better coordinated here, with clear >> incremental steps. >> >> However, when it was announced that the project could collapse, I >> reflected that we were a quite a few consuming the lib, possibly >> interested in getting involved, but striving to follow the upgrade >> path. By that time, v2.4 was the common version around, and with >> 2.9.2 the upgrade path towards 3.0 by replacing all the obsolete constructs >> was already a pain. >> >> I know several integrators could not be bothered, yet we did make >> those changes, and by the time we were finally ready to move on with >> the latest upgrades, you guys added a constraint, which resulted in a >> complete show stopper for us: .Net Framework 4.0. I understand that >> it feels natural for anything fresh, but with that decision you >> probably lost those, who like us have their products packaged with >> Lucene.Net in many existing environments where moving to .Net 4.0 is neither >> an option nor a decision of ours. >> >> Since then, we have kept investing into our 2.9.2 integration, but it >> will be months at the very least until we can consider imposing .Net >> 4.0 as a requirement for any further upgrades to our products. >> I'm pretty sure there are quite a few of us in that situation, which >> feels a bit similar to when we were many stuck with 2.4.1 constructs >> while help was requested to upgrade past 2.9.2. >> >> I guess you get the idea: it's a good thing if the project moves fast >> because of a few committers deeply involved, but it's as important to >> make sure most traditional integrators are following behind. >> >> Cheers, >> >> Jesse >> >> >> >> -----Message d'origine----- >> De : Prescott Nasser [mailto:geobmx...@hotmail.com] Envoyé : mercredi >> 1 février 2012 18:38 À : lucene-net-...@incubator.apache.org >> Objet : [Lucene.Net] Graduation >> >> Stefan has it on his agenda to get us to graduate, so I wanted to >> kick off a conversation on how we feel about that - do we feel we are >> ready? Why/why not. What are all the steps we need to take, etc. >> >> My two cents, Im worried about the sustainability of our community. I >> feel like we are a very small group working on this and that if one >> or two key players left we'd be in a ton of trouble. We haven't >> really developed great sustainable momentum, more like great bursts >> of effort then nothing for a while. >> >> We have also yet to fully determine the path we wish to take with the >> code base, seems we are split with a line by line and something that >> more closely resembles the .net world. I fear without determining our >> goals we might fumble, which id rather do in the incubator. >> >> -P >>
