We''ve had some discussion in the past about the wxruby vs wxruby-swig name, and how they are a bit confusing. My big problem with ''wxruby-swig'' is that unless you know what ''swig'' is, it''s not a terribly useful (or sexy) postfix. It''s like naming a car after it''s manufacturing process - "the all new Acura NSX-smoke-burning-factory" just wouldn''t sell cars. In the past, there was a good reason for the naming - one was supposed to replace the other quickly and silently. Well, that didn''t happen as expected. However, wxruby-swig has gained two real features. First, as you hungry list followers have heard, Zach has been completly redoing our documentation system with Rubydoc. As much as I complain about the web-layout defaults of rubydoc, no one can deny that these will be a huge improvement over our original docs. Second, wxruby-swig now works with wxWidgets 2.5.3 (tested with both Mac OS X and Win32). Windows users won''t be able to see much, but let me tell you (five) Mac OS X developers out there - It''s a big improvement. This brings me to the point of the email - what if we we changed the names "wxruby / wxruby-swig" to "wxruby-2.4 / wxruby-2.5", after the version of wxWidgets they supported? To me this makes more sense than the ''swig'' postfix, because it passes useful information. I''d like some discussion on this, because I''d like a proper name before this gets released. In closing, I''m really excited how wxruby-swig/2.5 is shaping up. It''s one of the only GUI''s for Ruby that really support Linux, Mac, and OS X well. Nick
I like it! Curt> -----Original Message----- > From: wxruby-users-bounces@rubyforge.org > [mailto:wxruby-users-bounces@rubyforge.org]On Behalf Of Nick > Sent: Sunday, February 20, 2005 5:42 PM > To: General discussion of wxRuby > Subject: [Wxruby-users] Suggestion for wxruby name change > > > > We''ve had some discussion in the past about the wxruby vs wxruby-swig > name, and how they are a bit confusing. My big problem with > ''wxruby-swig'' is that unless you know what ''swig'' is, it''s not a > terribly useful (or sexy) postfix. It''s like naming a car after it''s > manufacturing process - "the all new Acura NSX-smoke-burning-factory" > just wouldn''t sell cars. > > In the past, there was a good reason for the naming - one was supposed > to replace the other quickly and silently. Well, that didn''t happen as > expected. However, wxruby-swig has gained two real features. First, as > you hungry list followers have heard, Zach has been completly redoing > our documentation system with Rubydoc. As much as I complain about the > web-layout defaults of rubydoc, no one can deny that these will be a > huge improvement over our original docs. Second, wxruby-swig now works > with wxWidgets 2.5.3 (tested with both Mac OS X and Win32). Windows > users won''t be able to see much, but let me tell you (five) Mac OS X > developers out there - It''s a big improvement. > > This brings me to the point of the email - what if we we changed the > names "wxruby / wxruby-swig" to "wxruby-2.4 / wxruby-2.5", after the > version of wxWidgets they supported? To me this makes more sense than > the ''swig'' postfix, because it passes useful information. I''d like some > discussion on this, because I''d like a proper name before this gets > released. > > In closing, I''m really excited how wxruby-swig/2.5 is shaping up. It''s > one of the only GUI''s for Ruby that really support Linux, Mac, and OS X > well. > > Nick > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > -- > No virus found in this incoming message. > Checked by AVG Anti-Virus. > Version: 7.0.300 / Virus Database: 266.1.0 - Release Date: 2/18/2005 >
Nick wrote:> In the past, there was a good reason for the naming - one was supposed > to replace the other quickly and silently. Well, that didn''t happen as > expected....or hasn''t happened _yet_. Well, I suppose the "quickly and silently" bit is hopeless, but the "replace" could still happen. How far are we from saying that the swig version of wxruby is THE main, supported version?> This brings me to the point of the email - what if we we changed the > names "wxruby / wxruby-swig" to "wxruby-2.4 / wxruby-2.5", after the > version of wxWidgets they supported?I don''t really like this, partly because of the possible confusion when wxWidgets 2.6 is released.> To me this makes more sense than the ''swig'' postfix,Yes, clearly. wxruby-swig was really intended to be an internal name, and not the public project name. Perhaps wxruby-swig should become wxruby-2.0? Or perhaps wxruby should be renamed to wxruby-legacy? Those are my thoughts, but it''s definitely your decision. Kevin
Hi, Nick wrote:> It''s like naming a car after it''s manufacturing process - "the all > new Acura NSX-smoke-burning-factory" just wouldn''t sell cars.LOL !> In the past, there was a good reason for the naming - one was supposed > to replace the other quickly and silently. Well, that didn''t happen as > expected. However, wxruby-swig has gained two real features. First, as > you hungry list followers have heard, Zach has been completly redoing > our documentation system with Rubydoc. As much as I complain about the > web-layout defaults of rubydoc, no one can deny that these will be a > huge improvement over our original docs.No denying that ! Terrific work, Zach!> Second, wxruby-swig now works with wxWidgets 2.5.3 (tested with both > Mac OS X and Win32). Windows users won''t be able to see much, but let > me tell you (five) Mac OS X developers out there - It''s a big > improvement. > > This brings me to the point of the email - what if we we changed the > names "wxruby / wxruby-swig" to "wxruby-2.4 / wxruby-2.5", after the > version of wxWidgets they supported? To me this makes more sense than > the ''swig'' postfix, because it passes useful information. I''d like > some discussion on this, because I''d like a proper name before this > gets released.I do not see any compelling reason to change the name. Of course, non-swig to swig is a big jump and we can denote that by setting the version to 1.0 (or even 2.0 as Kevin suggested). But the name can still stay simply wxRuby. Just my $0.02.> In closing, I''m really excited how wxruby-swig/2.5 is shaping up. It''s > one of the only GUI''s for Ruby that really support Linux, Mac, and OS > X well.We all share your excitement.> NickThanks, -- shanko
Nick wrote:> > We''ve had some discussion in the past about the wxruby vs wxruby-swig > name, and how they are a bit confusing. My big problem with > ''wxruby-swig'' is that unless you know what ''swig'' is, it''s not a > terribly useful (or sexy) postfix. It''s like naming a car after it''s > manufacturing process - "the all new Acura NSX-smoke-burning-factory" > just wouldn''t sell cars.I agree.> In the past, there was a good reason for the naming - one was supposed > > to replace the other quickly and silently. Well, that didn''t happen as > expected. However, wxruby-swig has gained two real features. First, as > you hungry list followers have heard, Zach has been completly redoing > our documentation system with Rubydoc. As much as I complain about the > web-layout defaults of rubydoc, no one can deny that these will be a > huge improvement over our original docs. Second, wxruby-swig now works > with wxWidgets 2.5.3 (tested with both Mac OS X and Win32). Windows > users won''t be able to see much, but let me tell you (five) Mac OS X > developers out there - It''s a big improvement.I''m excited about wxRuby using wxWindows 2.5.3, as i''m sure others are. This is awesome for wxRuby on sooo many levels (wxWindows 2.5.x supports alpha transparency to!)> > This brings me to the point of the email - what if we we changed the > names "wxruby / wxruby-swig" to "wxruby-2.4 / wxruby-2.5", after the > version of wxWidgets they supported? To me this makes more sense than > the ''swig'' postfix, because it passes useful information. I''d like some > discussion on this, because I''d like a proper name before this gets > released.I think naming wxRuby after the wxWindows version will be more confusing then helpful, since wxRuby will need it''s own versioning to support its own features, compatibility with wxWindows and of course bug fixes, etc... but i agree about dropping the ''-swig'' postfix.> > In closing, I''m really excited how wxruby-swig/2.5 is shaping up. It''s > one of the only GUI''s for Ruby that really support Linux, Mac, and OS X > well. >I''m very excited as well, keep up the great work! Zach
> How far are we from saying that the swig version of wxruby is THE main,> supported version? That''s not really the issue - the issue is "when is a good time to get a binary built for people to try?" What has been holding that up is feature creep on the Mac OS X side. First, the issue was that wxruby-swig didn''t work with ruby 1.6.8 which is the ruby installed by default on the Mac. Because of this there really wasn''t a way to make a generic "installer" for the Mac (who are you installing for? Where is the distro?) so I changed gears and tried to make it into a Mac OS X "framework" that could be installed, hoping the stub library that would connect to it would work against all rubies (quick answer: no, its never that easy). At that point, the list "voted" that wxruby-swig needed to support wxWidgets 2.5, so once again I had to take on new development. In the meantime, I told Zach to begin working on the new docs for wxruby-swig. Just today I''ve gotten the Mac OS X build to link and run off the wxwidgets 2.5 library. As far as the original problem of installers on Mac OS X, the two main "binary ruby maintainers" on the Mac (Fink and Darwinports) have both said they would provide wxruby in packages for their distros. I conclude that they provide installers for their users, and anybody else on the Mac needs to build it from source because if they''re using ruby 1.8 on the Mac they had to build it from source in the first place. Zach''s docs are making progress, and are a definite improvement. I know I should have put out a Linux/Win32 binary build out for people to test (since thats the majority of our downloads), but when we lost you we lost our main Linux developer, and I was not in a position to handle bug requests on the Win32/Linux side and do the necessary Mac OS X development (and start a new job...). So now my goal is to tune up wxruby-swig and let Zach get the documentation ready, and release a test version to the masses. As far as being *the* version - experience tells me the migration won''t be without bumps. I''ve ported a lot of the classes, but I know I''m missing somebody''s favorite control/class and all this infrastructure work has taken time away from the addition of classes. The Layout classes are currently not functioning which I need to investigate (I was always more of an XRC fan, so it hasn''t been a high priority). And some people may just like the old widgets. Change never comes without friction. > I don''t really like this, partly because of the possible confusion when > wxWidgets 2.6 is released. Really, I see this as a naming scheme for the binaries. So our released files would be wxruby-2.4-src-0.7.tar.gz wxruby-2.4-msw-0.7.exe wxruby-2.4-osx-panther-0.7.dmg wxruby-2.5-src-0.1.tar.gz wxruby-2.5-msw-0.1.exe wxruby-2.5-osx-panther-0.1.dmg Some comments. First, the current tree would "stick around", possibly until downloads for the new surpass downloads for the old. It does require keeping up maintenance on the old tree. However, there are many good reasons to do so. First, the old tree supports more systems (Free BSD, MinGW) than the new one does, and it will for a long time. Second, the old tree has been tested and passed over a lot more eyes than the new system has. About the "dual version numbers" - yeah, I dunno about that. It''s confusing, I''ll admit. I think it''s clearer to wxWidgets users, but scarier to ruby users. > Perhaps wxruby-swig should become wxruby-2.0? Or perhaps wxruby should > be renamed to wxruby-legacy? To me, "legacy" = "less", and the current tree is still more battle tested. Same with 2.0 on wxruby-swig - it suggests it''s the superior version, which it won''t be until the migration is done. Nick Kevin Smith wrote:> Nick wrote: > >> In the past, there was a good reason for the naming - one was supposed >> to replace the other quickly and silently. Well, that didn''t happen as >> expected. > > > ...or hasn''t happened _yet_. Well, I suppose the "quickly and silently" > bit is hopeless, but the "replace" could still happen. > > How far are we from saying that the swig version of wxruby is THE main, > supported version? > >> This brings me to the point of the email - what if we we changed the >> names "wxruby / wxruby-swig" to "wxruby-2.4 / wxruby-2.5", after the >> version of wxWidgets they supported? > > > I don''t really like this, partly because of the possible confusion when > wxWidgets 2.6 is released. > >> To me this makes more sense than the ''swig'' postfix, > > > Yes, clearly. wxruby-swig was really intended to be an internal name, > and not the public project name. > > Perhaps wxruby-swig should become wxruby-2.0? Or perhaps wxruby should > be renamed to wxruby-legacy? > > Those are my thoughts, but it''s definitely your decision. > > Kevin > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
> This brings me to the point of the email - what if we we changed the > names "wxruby / wxruby-swig" to "wxruby-2.4 / wxruby-2.5", after the > version of wxWidgets they supported? To me this makes more sense than > the ''swig'' postfix, because it passes useful information. I''d like some > discussion on this, because I''d like a proper name before this gets > released. >Hello I intend to package wxruby (both versions) for ubuntu/debian and was about to ask something similar :) . FWIW the packages providing python bindings are named after the wxgtk versions there so 2.4 and 2.5.3 right now. I too would vote for dropping -swig from the name. But would wxruby-swig only support wx >=2.5? If it built against both versions of wx then calling it wxruby-2.5 would be confusing. maybe instead of naming the old wxruby-legacy the new could be wxruby-ng? Equally subjective, but still preferable to -legacy IMHO Jani
Kevin Smith wrote:> > Nick wrote: > > In the past, there was a good reason for the naming - one was supposed > > to replace the other quickly and silently. Well, that didn''t happen as > > expected. > > ...or hasn''t happened _yet_. Well, I suppose the "quickly and silently" > bit is hopeless, but the "replace" could still happen. > > How far are we from saying that the swig version of wxruby is THE main, > supported version? > > > This brings me to the point of the email - what if we we changed the > > names "wxruby / wxruby-swig" to "wxruby-2.4 / wxruby-2.5", after the > > version of wxWidgets they supported? > > I don''t really like this, partly because of the possible confusion when > wxWidgets 2.6 is released. > > > To me this makes more sense than the ''swig'' postfix, > > Yes, clearly. wxruby-swig was really intended to be an internal name, > and not the public project name. > > Perhaps wxruby-swig should become wxruby-2.0? Or perhaps wxruby should > be renamed to wxruby-legacy?Interesting, that was precisely what I thought (the "legacy" part) as I was part way through reading Nick''s email. Anyway, your approach sounds perfectly reasonable to me. Curt> Those are my thoughts, but it''s definitely your decision. > > Kevin
Nick wrote:>> > Really, I see this as a naming scheme for the binaries. So our released > files would be > > wxruby-2.4-src-0.7.tar.gz > wxruby-2.4-msw-0.7.exe > wxruby-2.4-osx-panther-0.7.dmg > wxruby-2.5-src-0.1.tar.gz > wxruby-2.5-msw-0.1.exe > wxruby-2.5-osx-panther-0.1.dmgThis seems reasonable to me, I was just thinking it''d be wxruby-2.5.3, or wxruby-2.6. I didn''t realize the two sets of numbers in my first reply. Zach
Jani Monoses wrote:> I too would vote for dropping -swig from the name.I think we are unanimous in that.> But would wxruby-swig only support wx >=2.5? If it built against both > versions of wx then calling it wxruby-2.5 would be confusing.That''s a very good point. I can definitely imagine wxruby-swig being back-ported to wx 2.4 at some point. And, for that matter, if wxruby-swig doesn''t become a superset of the older wxruby, the older codebase might be tweaked to work with wx 2.5. I think linking the wxruby version numbers to wx version numbers is risky, but might be workable. I think trying to do that *AND* to also use version numbers to distinguish between swig and non-swig codebases at the same time is just too confusing.> maybe instead of naming the old wxruby-legacy the new could be > wxruby-ng? Equally subjective, but still preferable to -legacy IMHOI guess I look forward to the day when wxruby (the legacy version) no longer exists. At that point, I would hope that the current, modern, working, supported version would simply be named ''wxruby''. I suppose that shift could happen when it''s ready, but I would err on the side of renaming earlier rather than later, to try to steer people toward the swig version. That''s one way to get more people working on it. Perhaps a compromise would be to rename wxruby to wxruby-1 and wxruby-swig to wxruby-2 or wxruby-ng. Then, when wxruby-1 no longer has any advantage over wxruby-ng, wxruby-ng could be renamed to just wxruby? Kevin
On Feb 20, 2005, at 7:30 PM, Nick wrote:> Really, I see this as a naming scheme for the binaries. So our > released files would be > > wxruby-2.4-src-0.7.tar.gz > wxruby-2.4-msw-0.7.exe > wxruby-2.4-osx-panther-0.7.dmg > wxruby-2.5-src-0.1.tar.gz > wxruby-2.5-msw-0.1.exe > wxruby-2.5-osx-panther-0.1.dmgFWIW, I believe this is the scheme that wxPython uses, although they seem to have their normal version numbers incorporating the wxWidgets version as well (e.g. wxPython2.5-osx-ansi-2.5.3.1.dmg). wxPerl doesn''t seem to have a consistent versioning scheme, but the help files are named: wxPerl-0.19-wx-2.4.2-docs. I think either one of these is good. wxruby2.5-src-0.1.tar.gz, or wxruby-0.1-wx2.5.3-src.tar.gz. The first seems to say, "this is a product known as wxruby 2.5, and it''s the 0.1 version of it." The latter seems to say, "this is version 0.1 of wxruby, and it''s built against wxWidgets 2.5.3". I''m leaning slightly toward the first, but I think they both have merits. Marshall
> That''s a very good point. I can definitely imagine wxruby-swig being> back-ported to wx 2.4 at some point. And, for that matter, if > wxruby-swig doesn''t become a superset of the older wxruby, the older > codebase might be tweaked to work with wx 2.5. See, I don''t see that happening, and here''s why: while the older code can be made to support multiple wxWidgets versions via #ifdefs, wxruby-swig has to have the choose which library it is going to support at code-generation time. The generated code for 2.5 won''t really work with 2.4, and vice versa, unless we limit wxruby-swig to the overlap of 2.4 and 2.5 (which is a huge limit). I really don''t see a majority of the users learning the Rake build enviroment, and hence don''t expect any but a few power users to ever be able to use wxruby-swig for 2.4 > I guess I look forward to the day when wxruby (the legacy version) no > longer exists. At that point, I would hope that the current, modern, > working, supported version would simply be named ''wxruby''. That will only happen when the new version is in all ways superior to the old, and even then it''s questionable (See: Linux, Apache, PhP, Perl, Ruby...) I just want to know what a good naming scheme would be before I put this out. I guess I''m not a big fan of "2.0" or "next gen" because that usually goes with features (not "fatter code and less classes"). Since wxruby-swig has moved to support the more bleeding edge 2.5, it seems a more logical way to name it for new users. Nick Kevin Smith wrote:> Jani Monoses wrote: > >> I too would vote for dropping -swig from the name. > > > I think we are unanimous in that. > >> But would wxruby-swig only support wx >=2.5? If it built against both >> versions of wx then calling it wxruby-2.5 would be confusing. > > > That''s a very good point. I can definitely imagine wxruby-swig being > back-ported to wx 2.4 at some point. And, for that matter, if > wxruby-swig doesn''t become a superset of the older wxruby, the older > codebase might be tweaked to work with wx 2.5. > > I think linking the wxruby version numbers to wx version numbers is > risky, but might be workable. I think trying to do that *AND* to also > use version numbers to distinguish between swig and non-swig codebases > at the same time is just too confusing. > >> maybe instead of naming the old wxruby-legacy the new could be >> wxruby-ng? Equally subjective, but still preferable to -legacy IMHO > > > I guess I look forward to the day when wxruby (the legacy version) no > longer exists. At that point, I would hope that the current, modern, > working, supported version would simply be named ''wxruby''. I suppose > that shift could happen when it''s ready, but I would err on the side of > renaming earlier rather than later, to try to steer people toward the > swig version. That''s one way to get more people working on it. > > Perhaps a compromise would be to rename wxruby to wxruby-1 and > wxruby-swig to wxruby-2 or wxruby-ng. Then, when wxruby-1 no longer has > any advantage over wxruby-ng, wxruby-ng could be renamed to just wxruby? > > Kevin > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >