Hi, Following the exchange in the roadmap page (http://wxruby.rubyforge.org/wiki/wiki.pl?DevelopmentRoadmap), I''d like to discuss a few things regarding version management. First, I agree that we should limit the number of branches (i.e. trunk and current "wxruby_2_0_stable"). But wxruby-3.x is a bit far away and I''m a bit concerned by the bugfix only policy of the stable "2.0" branch : "Stable 2.0 This will be maintained as a branch in SVN, bugfixes only; no new classes. Guaranteed forward/backward compatibility within the 2.0.x series." 1/ I''d like to add in the stable "2.0" branch : - some samples (e.g. a revised sample of the old one from the wiki that makes use of RMagick with wxRuby) - some art work (i.e. icons derived from the new logo) in a new art folder (like in wxWidgets). I assume that this is OK as these additions cannot be considered new classes or new features. 2/ I''d like to see new features like the one for adding named arguments for Wx::Font constructor (http://rubyforge.org/tracker/?func=detail&atid=221&aid=24199&group_id=35) available in a near future and not only when wxruby-3.0 will be available. I think we should consider adding new features that are backward compatible with wxruby-2.0.0. This can be managed within a single branch (the current "wxruby_2_0_stable" branch) as following : a) I fully agree that a wxruby-2.0.x shall be backward and forward compatible with wxruby-2.0.0. b) But I also think that we can plan a minor version (e.g. 2.1.0) from time to time that will be only backward compatible : - wxruby-2.1.x shall be backward with wxruby-2.0.x. - but as there are new features, the forward compatibility is not guaranteed Cheers. Chauk-Mean.
Hey, I follow what your talking about, and I agree. But let''s put this into more terminal, tangible goals here. Mind you, this is just an example, always open to changes. 2.1.x - Start with modularizing the Library, and cleaning up the Bloat of the so file, as well as fixing various bugs. 2.2.x - New Formatting of Syntax for wxRuby. 2.3.x - Additional Classes that aren''t currently wrapped. 2.4.x - etc. 2.5.x - etc 3.0.x - Switch wxWidgets libraries to 3.0 release 3.x.x - Follow wxWidget''s release schedule. As I said, this is just an example, but we should focus on the tasks that we have listed in the Roadmap, and assign that specific task to a part of the 2.x chain version of wxRuby. I would also recommend that we do keep things separated as we have it in the Development Roadmap, cause if we try to cover to much in one Minor revision, we may end up shooting ourselves in the foot, and trying to go all over the place. What do you guys think? On Fri, Mar 13, 2009 at 8:47 AM, Chauk-Mean Proum <chauk.mean at gmail.com>wrote:> Hi, > > Following the exchange in the roadmap page > (http://wxruby.rubyforge.org/wiki/wiki.pl?DevelopmentRoadmap), I''d > like to discuss a few things regarding version management. > > First, I agree that we should limit the number of branches (i.e. trunk > and current "wxruby_2_0_stable"). > > But wxruby-3.x is a bit far away and I''m a bit concerned by the bugfix > only policy of the stable "2.0" branch : > > "Stable 2.0 > This will be maintained as a branch in SVN, bugfixes only; no new > classes. Guaranteed forward/backward compatibility within the 2.0.x > series." > > 1/ I''d like to add in the stable "2.0" branch : > - some samples (e.g. a revised sample of the old one from the wiki > that makes use of RMagick with wxRuby) > - some art work (i.e. icons derived from the new logo) in a new art > folder (like in wxWidgets). > I assume that this is OK as these additions cannot be considered new > classes or new features. > > 2/ I''d like to see new features like the one for adding named > arguments for Wx::Font constructor > (http://rubyforge.org/tracker/?func=detail&atid=221&aid=24199&group_id=35) > available in a near future and not only when wxruby-3.0 will be > available. > > I think we should consider adding new features that are backward > compatible with wxruby-2.0.0. This can be managed within a single > branch (the current "wxruby_2_0_stable" branch) as following : > > a) I fully agree that a wxruby-2.0.x shall be backward and forward > compatible with wxruby-2.0.0. > > b) But I also think that we can plan a minor version (e.g. 2.1.0) from > time to time that will be only backward compatible : > - wxruby-2.1.x shall be backward with wxruby-2.0.x. > - but as there are new features, the forward compatibility is not > guaranteed > > Cheers. > > Chauk-Mean. > _______________________________________________ > wxruby-development mailing list > wxruby-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-development >-- Mario Steele http://www.trilake.net http://www.ruby-im.net http://rubyforge.org/projects/wxruby/ http://rubyforge.org/projects/wxride/ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/wxruby-development/attachments/20090313/e3dddaae/attachment.html>
Hi Chauk-Mean Proum wrote:> 1/ I''d like to add in the stable "2.0" branch : > - some samples (e.g. a revised sample of the old one from the wiki > that makes use of RMagick with wxRuby) > - some art work (i.e. icons derived from the new logo) in a new art > folder (like in wxWidgets).I agree. Similarly additions to documentation. btw - thanks for checking in the logos. I would slightly prefer to have ''art'' as a subdirectory of ''share'', and this should to be added to the packaging if the samples are going to depend on it. I''ll add variant sizes of the logo + text.> b) But I also think that we can plan a minor version (e.g. 2.1.0) from > time to time that will be only backward compatible : > - wxruby-2.1.x shall be backward with wxruby-2.0.x. > - but as there are new features, the forward compatibility is not guaranteedI agree with this too. I meant feature frozen for the 2.*0* bit - but we could have 2.*2*, 2.4 etc with additional features and the compatibility rules you suggest. As to how we do it - suggest we work on new features (including wxWidgets 3.0) on trunk, rather than necessarily committing to a whole series of 2.x feature releases right away. We can assess in a few months - if wxWidgets 3.0 is a long way away, and there are useful features, we can make another branch from 2.0 and backport things (like the Font ctor, additional classes) from trunk to it. The important files in swig/class should be largely transferable between 2.x and 3.x. wxWidgets 3.0 may not be so far away tho: http://lists.wxwidgets.org/pipermail/wx-dev/2009-March/112695.html We''ll try and keep trunk working with Ruby 1.8 and Ruby 1.9 for now too. The two main things I can see improving using 1.9 is more efficient event dispatch (at the moment, it goes through a couple of layers of ''call'') and better string handling (so that strings of any encoding can be passed in). a
Hi, On Wed, Mar 18, 2009 at 12:18 AM, Alex Fenton <alex at pressure.to> wrote:> Chauk-Mean Proum wrote: >> >> 1/ I''d like to add in the stable "2.0" branch : >> - some samples (e.g. a revised sample of the old one from the wiki >> that makes use of RMagick with wxRuby) >> - some art work (i.e. icons derived from the new logo) in a new art >> folder (like in wxWidgets). > > I agree. Similarly additions to documentation. > > btw - thanks for checking in the logos. I would slightly prefer to have > ''art'' as a subdirectory of ''share'',What is expected to be put in the share directory in addition to the art subdirectory ? I would find it strange if there is nothing else.> and this should to be added to the > packaging if the samples are going to depend on it.Oups. I''ve just forgotten to do that.>> b) But I also think that we can plan a minor version (e.g. 2.1.0) from >> time to time that will be only backward compatible : >> - wxruby-2.1.x shall be backward with wxruby-2.0.x. >> - but as there are new features, the forward compatibility is not >> guaranteed > > I agree with this too. I meant feature frozen for the 2.*0* bit ?- but we > could have 2.*2*, 2.4 etc with additional features and the compatibility > rules you suggest.Fine. Cheers. Chauk-Mean.