Re: Next release?
Hi, On Tue, Feb 19, 2008 at 11:14 PM, Andrzej Bialecki [EMAIL PROTECTED] wrote: Hi all, I propose to start planning for the next release, and tentatively I propose to schedule it for the beginning of April. I'm going to close a lot of old and outdated issues in JIRA - other committers, please do the same if you know that a given issue no longer applies. There are some issues I want to put in before a release. Most are trivial but I would like to draw attention to NUTCH-442, as it is an issue that I (and looking at its votes, others) want to see resolved before another release. I really could use some review and suggestions there (well, I guess I am partly to blame since I failed to update the patch after Enis's comments). Out of the remaining open issues, we should resolve all with the blocker / major status, and of the type bug. Then we can resolve as many as we can from the remaining categories, depending on the votes and perceived importance of the issue. Any other suggestions? -- Best regards, Andrzej Bialecki ___. ___ ___ ___ _ _ __ [__ || __|__/|__||\/| Information Retrieval, Semantic Web ___|||__|| \| || | Embedded Unix, System Integration http://www.sigram.com Contact: info at sigram dot com -- Doğacan Güney
Re: Next release?
Andrzej Bialecki wrote: Hi all, I propose to start planning for the next release, and tentatively I propose to schedule it for the beginning of April. Sounds good. I'm going to close a lot of old and outdated issues in JIRA - other committers, please do the same if you know that a given issue no longer applies. Will try to do the same. Out of the remaining open issues, we should resolve all with the blocker / major status, and of the type bug. Then we can resolve as many as we can from the remaining categories, depending on the votes and perceived importance of the issue. Any other suggestions? There are a few things I have been working on that may be ready for this release (maybe not): 1) Ordering inlinks by OPIC score, that way the best inlinks are saved and indexed. 2) URL translation. This would deal with having a tool to map url A to url B and would run on fetched segments. 3) Maybe some better distributed search server management code (if time). Dennis
Re: Next release?
Doğacan Güney wrote: There are some issues I want to put in before a release. Most are trivial but I would like to draw attention to NUTCH-442, as it is an issue that I (and looking at its votes, others) want to see resolved before another release. I really could use some review and suggestions there (well, I guess I am partly to blame since I failed to update the patch after Enis's comments). I agree, this is an important issue. Sigh, it's time to review this 200kB patch .. ;) -- Best regards, Andrzej Bialecki ___. ___ ___ ___ _ _ __ [__ || __|__/|__||\/| Information Retrieval, Semantic Web ___|||__|| \| || | Embedded Unix, System Integration http://www.sigram.com Contact: info at sigram dot com
Next release?
Hi all, I propose to start planning for the next release, and tentatively I propose to schedule it for the beginning of April. I'm going to close a lot of old and outdated issues in JIRA - other committers, please do the same if you know that a given issue no longer applies. Out of the remaining open issues, we should resolve all with the blocker / major status, and of the type bug. Then we can resolve as many as we can from the remaining categories, depending on the votes and perceived importance of the issue. Any other suggestions? -- Best regards, Andrzej Bialecki ___. ___ ___ ___ _ _ __ [__ || __|__/|__||\/| Information Retrieval, Semantic Web ___|||__|| \| || | Embedded Unix, System Integration http://www.sigram.com Contact: info at sigram dot com
Next release - 0.10.0 or 1.0.0 ?
Hi all, I know it's a trivial issue, but still ... When this release is out, I propose that we should name the next release 1.0.0, and not 0.10.0. The effect is purely psychological, but it also reflects our confidence in the platform. Many Open Source projects are afraid of going to 1.0.0 and seem to be unable to ever reach this level, as if it were a magic step beyond which they are obliged to make some implied but unjustified promises ... Perhaps it's because in the commercial world everyone knows what a 1.0.0 release means :) The downside of the version numbering that never reaches 1.0.0 is that casual users don't know how usable the software is - e.g. Nutch 0.10.0 could possibly mean that there are still 90 releases to go before it becomes usable. Therefore I propose the following: * shorten the release cycle, so that we can make a release at least once every quarter. This was discussed before, and I hope we can make it happen, especially with the help of new forces that joined the team ;) * call the next version 1.0.0, and continue in increments of 0.1.0 for each bi-monhtly or quarterly release, * make critical bugfix / maintenance releases using increments of 0.0.1 - although the need for such would be greatly diminished with the shorter release cycle. * once we arrive at versions greater than x.5.0 we should plan for a big release (increment of 1.0.0). * we should use only single digits for small increments, i.e. limit them to values between 0-9. What do you think? -- Best regards, Andrzej Bialecki ___. ___ ___ ___ _ _ __ [__ || __|__/|__||\/| Information Retrieval, Semantic Web ___|||__|| \| || | Embedded Unix, System Integration http://www.sigram.com Contact: info at sigram dot com
RE: Next release - 0.10.0 or 1.0.0 ?
Another way of looking at it might be to ask the question what would make a great 1.0 release? What new features would be awesome? What might get people more excited? Having a 1.0 might make the project look like it has attained a real milestone. Steve -Original Message- From: Andrzej Bialecki [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 28, 2007 2:38 PM To: nutch-dev@lucene.apache.org Subject: Next release - 0.10.0 or 1.0.0 ? Hi all, I know it's a trivial issue, but still ... When this release is out, I propose that we should name the next release 1.0.0, and not 0.10.0. The effect is purely psychological, but it also reflects our confidence in the platform. Many Open Source projects are afraid of going to 1.0.0 and seem to be unable to ever reach this level, as if it were a magic step beyond which they are obliged to make some implied but unjustified promises ... Perhaps it's because in the commercial world everyone knows what a 1.0.0 release means :) The downside of the version numbering that never reaches 1.0.0 is that casual users don't know how usable the software is - e.g. Nutch 0.10.0 could possibly mean that there are still 90 releases to go before it becomes usable. Therefore I propose the following: * shorten the release cycle, so that we can make a release at least once every quarter. This was discussed before, and I hope we can make it happen, especially with the help of new forces that joined the team ;) * call the next version 1.0.0, and continue in increments of 0.1.0 for each bi-monhtly or quarterly release, * make critical bugfix / maintenance releases using increments of 0.0.1 - although the need for such would be greatly diminished with the shorter release cycle. * once we arrive at versions greater than x.5.0 we should plan for a big release (increment of 1.0.0). * we should use only single digits for small increments, i.e. limit them to values between 0-9. What do you think? -- Best regards, Andrzej Bialecki ___. ___ ___ ___ _ _ __ [__ || __|__/|__||\/| Information Retrieval, Semantic Web ___|||__|| \| || | Embedded Unix, System Integration http://www.sigram.com Contact: info at sigram dot com
Re: Next release - 0.10.0 or 1.0.0 ?
+1 Andrzej Bialecki wrote: Hi all, I know it's a trivial issue, but still ... When this release is out, I propose that we should name the next release 1.0.0, and not 0.10.0. The effect is purely psychological, but it also reflects our confidence in the platform. I think that a 1.0 release signifies maturity. And while I think there are areas that Nutch can and will improve, I think that it has reached the necessary maturity level. Many Open Source projects are afraid of going to 1.0.0 and seem to be unable to ever reach this level, as if it were a magic step beyond which they are obliged to make some implied but unjustified promises ... Perhaps it's because in the commercial world everyone knows what a 1.0.0 release means :) The downside of the version numbering that never reaches 1.0.0 is that casual users don't know how usable the software is - e.g. Nutch 0.10.0 could possibly mean that there are still 90 releases to go before it becomes usable. Personally, I don't like the x.10.x release structure. I guess I think that if you can't get what you need done in 10 releases x.0.x - x.9.x then some rework needs to be done. Think about this, eclipse is still only on 3.2.2 / 3.3 and they use this type of structure. Therefore I propose the following: * shorten the release cycle, so that we can make a release at least once every quarter. This was discussed before, and I hope we can make it happen, especially with the help of new forces that joined the team ;) I agree. * call the next version 1.0.0, and continue in increments of 0.1.0 for each bi-monhtly or quarterly release, I agree with bi-monthly or monthly. I think quarterly is too long especially considering how fast Hadoop is moving. * make critical bugfix / maintenance releases using increments of 0.0.1 - although the need for such would be greatly diminished with the shorter release cycle. Yes but some bug fixes will still be necessary even with shortened release cycles. * once we arrive at versions greater than x.5.0 we should plan for a big release (increment of 1.0.0). I am fine having 10 releases x.0 - x.9 per major release. Maybe I don't understand the reason for limiting it to 5 other than. If we do a release every month or so then about once a year we should have a major X release. * we should use only single digits for small increments, i.e. limit them to values between 0-9. Agree. What do you think?
Re: Next release - 0.10.0 or 1.0.0 ?
My +1 for 1.0.0. I already changed it to 0.10.0, but this can be easily reverted, and was probably something that I should have brought to the attention of the dev list before I did that (sorry about that). In any case, I think 1.0.0 makes a lot of sense, politically, and software wise. Nutch is production quality software (we use it in production environments here at JPL), and deserves to have a 1.0.0 release... My 2 cents, Chris On 3/28/07 11:38 AM, Andrzej Bialecki [EMAIL PROTECTED] wrote: Hi all, I know it's a trivial issue, but still ... When this release is out, I propose that we should name the next release 1.0.0, and not 0.10.0. The effect is purely psychological, but it also reflects our confidence in the platform. Many Open Source projects are afraid of going to 1.0.0 and seem to be unable to ever reach this level, as if it were a magic step beyond which they are obliged to make some implied but unjustified promises ... Perhaps it's because in the commercial world everyone knows what a 1.0.0 release means :) The downside of the version numbering that never reaches 1.0.0 is that casual users don't know how usable the software is - e.g. Nutch 0.10.0 could possibly mean that there are still 90 releases to go before it becomes usable. Therefore I propose the following: * shorten the release cycle, so that we can make a release at least once every quarter. This was discussed before, and I hope we can make it happen, especially with the help of new forces that joined the team ;) * call the next version 1.0.0, and continue in increments of 0.1.0 for each bi-monhtly or quarterly release, * make critical bugfix / maintenance releases using increments of 0.0.1 - although the need for such would be greatly diminished with the shorter release cycle. * once we arrive at versions greater than x.5.0 we should plan for a big release (increment of 1.0.0). * we should use only single digits for small increments, i.e. limit them to values between 0-9. What do you think?
