Any chance of incrementing the ol'' version number a bit more aggressively? Doing so could really help wxRuby adoption if done right: http://fishbowl.pastiche.org/2003/07/28/version_numbers_and_you -- Ryan "John" Platte Custom services, NIKA Consulting http://nikaconsulting.com/
John Platte wrote:> > Any chance of incrementing the ol'' version number a bit more > aggressively? Doing so could really help wxRuby adoption if done right: > > http://fishbowl.pastiche.org/2003/07/28/version_numbers_and_youThanks for the link! I think you''ve got a real good point here (I forwarded this to the FreeRIDE project as well). A real good question to ask ourselves is precisely *what* should be completed before we would be willing to label it 0.9 or 1.0. For wxRuby, I think that the memory management problems should be fixed. What else? Curt
For the Mac, it would be 1) Exist as a framework 2) Getting the samples to work as easily as their other platform counterparts 3) Documentation Speaking of, I just recently saw the question mark on the wxruby news for Mac info. Should I write some getting started text? Nick Curt Hibbs wrote:>John Platte wrote: > > >>Any chance of incrementing the ol'' version number a bit more >>aggressively? Doing so could really help wxRuby adoption if done right: >> >>http://fishbowl.pastiche.org/2003/07/28/version_numbers_and_you >> >> > >Thanks for the link! I think you''ve got a real good point here (I forwarded >this to the FreeRIDE project as well). > >A real good question to ask ourselves is precisely *what* should be >completed before we would be willing to label it 0.9 or 1.0. For wxRuby, I >think that the memory management problems should be fixed. What else? > >Curt > > >_______________________________________________ >wxruby-users mailing list >wxruby-users@rubyforge.org >http://rubyforge.org/mailman/listinfo/wxruby-users > > > >
Nick wrote:> > Speaking of, I just recently saw the question mark on the wxruby news > for Mac info. Should I write some getting started text?No, just a mistake on my part (missing spaces) that created an accidental wiki link. I just fixed it. Curt
On 2004 Apr 21, at 10:17, Curt Hibbs wrote:>> Any chance of incrementing the ol'' version number a bit more >> aggressively? Doing so could really help wxRuby adoption if done >> right: >> >> http://fishbowl.pastiche.org/2003/07/28/version_numbers_and_you > > Thanks for the link! I think you''ve got a real good point here (I > forwarded > this to the FreeRIDE project as well). > > A real good question to ask ourselves is precisely *what* should be > completed before we would be willing to label it 0.9 or 1.0. For > wxRuby, I > think that the memory management problems should be fixed. What else?In the proprietary software world, a first public beta release is, say, 0.9, and a well-smoke-tested release (like I believe wxRuby is now) can be called 1.0. What may be a gamma or beta to quality-minded coders like this team is what many software consumers expect from a 1.0 release. Then increased adoption can accelerate development through increased feedback and hopefully contributions. As long as the release notes document the question marks still remaining, I believe users (particularly developers, who are the target audience) will accept this as a 1.0. Kevin has moved to darcs specifically to make concurrent work easier -- which suggests to me that if wxRuby is anywhere near presentable (sure seems to be), the best move may be to welcome the bazaar to the door. What if, for example...? 1) the release of the RubyGems marks 1.0 2) memory management work can go toward 1.0.1+ if done pre-SWIG 3) there''s a 1.1 development branch for the SWIG implementation 4) 1.2 is the first stable SWIG release 5) improvements on the SWIG release (like memory management) increment the "teeny" third number if minor, the "minor" second number if folks will notice or the API changes You all have put in a lot of work, and it shows. Flaunt it, for the good of the project! P.S. Another link for consideration: http://www.randsinrepose.com/archives/2004/04/19/heinous.html -- Ryan "John" Platte Custom services, NIKA Consulting http://nikaconsulting.com/
A few concerns about proclaiming 1.0. A lot of this falls under personal opinion. 1) It that it implies the API has stabilized, which I''m not quite sure everything has quite yet. Obviously we''re tacked onto a pretty stable API already (wxWidgets 2.4.2), but for example in version 0.2 there was the addition of the ''paint'' method to Window, which makes DC work possible in a very ruby-esque way. There''s still a bit of a chance we may need to make a major overhaul in the ''busty innards'' to fix major problems, like the GC ownership problems. 2) How far do we support 1.0, when we know most of it will basically be nuked by wxruby-swig? I fear people hanging onto 1.0 branch because they''re scared of the experimental 2.0. Do we have two branches (like Apache) that continue on? 3) I''d like to think that major number changes imply API changes, while minor numbers imply bug fixes. We''re missing so much from wxWidgets, that every release would be a major number change. I agree that we should come up with 1.0 means, and I have had people get qweasy about the 0.3 buisness. But I still see this project as going forward towards the uber-ultimate ruby widget set, not resting on how much has been done. There is still a *lot* to do <sobs>. My $0.02 Nick John Platte wrote:> On 2004 Apr 21, at 10:17, Curt Hibbs wrote: > >>> Any chance of incrementing the ol'' version number a bit more >>> aggressively? Doing so could really help wxRuby adoption if done right: >>> >>> http://fishbowl.pastiche.org/2003/07/28/version_numbers_and_you >> >> >> Thanks for the link! I think you''ve got a real good point here (I >> forwarded >> this to the FreeRIDE project as well). >> >> A real good question to ask ourselves is precisely *what* should be >> completed before we would be willing to label it 0.9 or 1.0. For >> wxRuby, I >> think that the memory management problems should be fixed. What else? > > > In the proprietary software world, a first public beta release is, > say, 0.9, and a well-smoke-tested release (like I believe wxRuby is > now) can be called 1.0. > > What may be a gamma or beta to quality-minded coders like this team is > what many software consumers expect from a 1.0 release. Then increased > adoption can accelerate development through increased feedback and > hopefully contributions. As long as the release notes document the > question marks still remaining, I believe users (particularly > developers, who are the target audience) will accept this as a 1.0. > > Kevin has moved to darcs specifically to make concurrent work easier > -- which suggests to me that if wxRuby is anywhere near presentable > (sure seems to be), the best move may be to welcome the bazaar to the > door. > > What if, for example...? > > 1) the release of the RubyGems marks 1.0 > 2) memory management work can go toward 1.0.1+ if done pre-SWIG > 3) there''s a 1.1 development branch for the SWIG implementation > 4) 1.2 is the first stable SWIG release > 5) improvements on the SWIG release (like memory management) increment > the "teeny" third number if minor, the "minor" second number if folks > will notice or the API changes > > You all have put in a lot of work, and it shows. Flaunt it, for the > good of the project! > > P.S. Another link for consideration: > http://www.randsinrepose.com/archives/2004/04/19/heinous.html >
On 2004 Apr 21, at 12:06, Nick wrote:> A few concerns about proclaiming 1.0. A lot of this falls under > personal opinion.And I believe 100% of my comments today are personal opinion. Conversation starter.> 1) It that it implies the API has stabilized, which I''m not quite sure > everything has quite yet. Obviously we''re tacked onto a pretty stable > API already (wxWidgets 2.4.2), but for example in version 0.2 there > was the addition of the ''paint'' method to Window, which makes DC work > possible in a very ruby-esque way. There''s still a bit of a chance we > may need to make a major overhaul in the ''busty innards'' to fix major > problems, like the GC ownership problems.Question: But should you stay in the 0.x ghetto (0.3, at that!) just because *some* of the API *might* change by an undetermined amount?> 2) How far do we support 1.0, when we know most of it will basically > be nuked by wxruby-swig? I fear people hanging onto 1.0 branch because > they''re scared of the experimental 2.0. Do we have two branches (like > Apache) that continue on?My idea was that 1.0 could be the current state, a 1.1.x could be the SWIG betas, and 1.2 could be the SWIG release. As for people''s fears, the way you state things can have a lot of impact. Kevin seems to check things out very carefully, and he reports success so far in the move to SWIG -- couldn''t the ChangeLog for 1.2 simply state "Moved to SWIG for increased life satisfaction"? If you''re nervous about all this, you could mark the current state as 0.8, or "as stable as we''re going to get before SWIG", use 0.9.x for the SWIG pre-releases, and use 1.0 for the SWIG release. Of course, the main idea is to communicate wxRuby''s readiness more accurately, since the version number is a numeric progress indicator you send out every time anything''s announced about the project.> 3) I''d like to think that major number changes imply API changes, > while minor numbers imply bug fixes. We''re missing so much from > wxWidgets, that every release would be a major number change.My terminology was from what I''ve seen in Makefiles (like Ruby''s), where version numbers are specified as $(MAJOR).$(MINOR).$(TEENY). Given the nature of this project, I would imagine the major number creeping up quite slowly -- perhaps notch it up to 2.0 when it''s complete and stable to the point of really taking off?> I agree that we should come up with 1.0 means, and I have had people > get qweasy about the 0.3 buisness. But I still see this project as > going forward towards the uber-ultimate ruby widget set, not resting > on how much has been done. There is still a *lot* to do <sobs>. > > My $0.02Yes, my comments are shooting toward the goal of getting more eyeballs on the code -- I just also wanted to mention that the hard work is getting somewhere. And again, please note my opinion is worth less than $0.02 -- I''m just trying to catalyze a move most folks here might want anyway. Saw the article and thought of you guys. -- Ryan "John" Platte Custom services, NIKA Consulting http://nikaconsulting.com/
I haven''t had time yet to read your posting in detail, but I to give it a 0.9 or 1.0 it would (at a minimum have to be stable enough not to segfault with gc problems. Curt John Platte wrote:> Sent: Wednesday, April 21, 2004 2:06 PM > To: Wxruby developers'' list > Subject: Re: [Wxruby-users] mythical 1.0 > > > On 2004 Apr 21, at 12:06, Nick wrote: > > > A few concerns about proclaiming 1.0. A lot of this falls under > > personal opinion. > > And I believe 100% of my comments today are personal opinion. > Conversation starter. > > > 1) It that it implies the API has stabilized, which I''m not quite sure > > everything has quite yet. Obviously we''re tacked onto a pretty stable > > API already (wxWidgets 2.4.2), but for example in version 0.2 there > > was the addition of the ''paint'' method to Window, which makes DC work > > possible in a very ruby-esque way. There''s still a bit of a chance we > > may need to make a major overhaul in the ''busty innards'' to fix major > > problems, like the GC ownership problems. > > Question: But should you stay in the 0.x ghetto (0.3, at that!) just > because *some* of the API *might* change by an undetermined amount? > > > 2) How far do we support 1.0, when we know most of it will basically > > be nuked by wxruby-swig? I fear people hanging onto 1.0 branch because > > they''re scared of the experimental 2.0. Do we have two branches (like > > Apache) that continue on? > > My idea was that 1.0 could be the current state, a 1.1.x could be the > SWIG betas, and 1.2 could be the SWIG release. As for people''s fears, > the way you state things can have a lot of impact. Kevin seems to check > things out very carefully, and he reports success so far in the move to > SWIG -- couldn''t the ChangeLog for 1.2 simply state "Moved to SWIG for > increased life satisfaction"? > > If you''re nervous about all this, you could mark the current state as > 0.8, or "as stable as we''re going to get before SWIG", use 0.9.x for > the SWIG pre-releases, and use 1.0 for the SWIG release. > > Of course, the main idea is to communicate wxRuby''s readiness more > accurately, since the version number is a numeric progress indicator > you send out every time anything''s announced about the project. > > > 3) I''d like to think that major number changes imply API changes, > > while minor numbers imply bug fixes. We''re missing so much from > > wxWidgets, that every release would be a major number change. > > My terminology was from what I''ve seen in Makefiles (like Ruby''s), > where version numbers are specified as $(MAJOR).$(MINOR).$(TEENY). > > Given the nature of this project, I would imagine the major number > creeping up quite slowly -- perhaps notch it up to 2.0 when it''s > complete and stable to the point of really taking off? > > > I agree that we should come up with 1.0 means, and I have had people > > get qweasy about the 0.3 buisness. But I still see this project as > > going forward towards the uber-ultimate ruby widget set, not resting > > on how much has been done. There is still a *lot* to do <sobs>. > > > > My $0.02 > > Yes, my comments are shooting toward the goal of getting more eyeballs > on the code -- I just also wanted to mention that the hard work is > getting somewhere. > > And again, please note my opinion is worth less than $0.02 -- I''m just > trying to catalyze a move most folks here might want anyway. Saw the > article and thought of you guys. > > -- > Ryan "John" Platte > Custom services, NIKA Consulting > http://nikaconsulting.com/ > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.662 / Virus Database: 425 - Release Date: 4/20/2004 >
On 2004 Apr 21, at 14:27, Curt Hibbs wrote:> I haven''t had time yet to read your posting in detail, but I to give > it a > 0.9 or 1.0 it would (at a minimum have to be stable enough not to > segfault > with gc problems.Sorry for the long post. One-sentence summary:>> ...you could mark the current state as 0.8, or "as stable as we''re >> going to get before SWIG", use 0.9.x for the SWIG pre-releases, and >> use 1.0 for the SWIG release.-- Ryan "John" Platte Custom services, NIKA Consulting http://nikaconsulting.com/
Curt Hibbs wrote:> John Platte wrote: > >>Any chance of incrementing the ol'' version number a bit more >>aggressively? Doing so could really help wxRuby adoption if done right: >> >>http://fishbowl.pastiche.org/2003/07/28/version_numbers_and_you > > Thanks for the link! I think you''ve got a real good point here (I forwarded > this to the FreeRIDE project as well).Yes, that''s a great little essay, and I agree completely! However, with wxRuby, the problem is less about version numbers, and more about progress being slower than I would like. :-( The reality is that wxRuby is not yet stable enough for widespread use.> A real good question to ask ourselves is precisely *what* should be > completed before we would be willing to label it 0.9 or 1.0. For wxRuby, I > think that the memory management problems should be fixed. What else?My goal is to switch to SWIG for the next version, and to call it 0.5. That should fix most of the memory problems, although perhaps not all of them. Release 0.5 must support at least all the classes and methods that 0.3 already supports. Once 0.5 has been tested enough, and any remaining memory problems have been fixed, I''m ok calling it 0.9, or even 1.0. My main criteria is that it would have to be something I would be comfortable using in a production application. I don''t think 1.0 must support every method of every wxWidgets class. It doesn''t have to have unicode support (although that would be great). The samples and docs might have to improve a bit, such as adding several more pages to the tutorial. Kevin
John Platte wrote:> In the proprietary software world, a first public beta release is, say, > 0.9, and a well-smoke-tested release (like I believe wxRuby is now) can > be called 1.0.I really appreciate you starting this conversation. Unfortunately, wxRuby really isn''t there yet. As Curt says, it''s not ok to have several known segfaults for simple operations. I suppose I''m like the guy inside the sausage factory who knows what''s really in this hot dog. With hindsight, wxRuby 0.1 probably could have been called 0.2. The 0.2 release probably could have been 0.5, and the 0.3 release could have been 0.6. Based on my swig work so far, I do not expect a long delay before the first swig-based release. I am also optimistic that it will be very stable. It''s always nice to have the luxury of starting over, but with tools that allow you to finish ten times faster :-)> Kevin has moved to darcs specifically to make concurrent work easier -- > which suggests to me that if wxRuby is anywhere near presentable (sure > seems to be), the best move may be to welcome the bazaar to the door.Actually, at the moment, any code submissions to the old code base will (if anything) slow things down. Submissions in the swig code base might help, but that''s not clear either. The learning curve is a bit high for casual submissions right now. Later, small fixes will be highly appreciated. What I really need most right now is non-Linux testers to test and help fix the new wxruby-swig build system. Next on my list would be improved samples and continued development of the tutorial.> 1) the release of the RubyGems marks 1.0If I thought the swig version were going to take a long time, I would suggest that the gem release could bump us to 0.5 or so. However, I think the swig-based 0.5 release should happen within a couple months.> 2) memory management work can go toward 1.0.1+ if done pre-SWIGCrashes (often memory-related) must be fixed pre-1.0. Leaks could be post-1.0.> You all have put in a lot of work, and it shows. Flaunt it, for the good > of the project!Thanks for the vote of confidence :-)> P.S. Another link for consideration: > http://www.randsinrepose.com/archives/2004/04/19/heinous.htmlAnother good essay that I completely agree with. I definitely want to avoid the trap of releasing fifty versions between 0.9 and 1.0. Kevin