Hi all, I am concerned about the version number for our gem. Currently, we have it set to 1.9, indicating that it is "before the upcoming 2.0 release". However, there is nothing in the version number that indicates this is a "preview" "alpha" "buggy" release. The gem version numbering scheme does not allow things like 2.0-pre. It also requires each public release of a gem to have a different version number. I now believe that we should call this wxruby 0.9.0. It is newer than wxruby 0.6.0 (which was never released as a gem, and probably never will be). It is not yet "1.0" quality. We can cycle through the 0.9.0 versions until we actually hit wxruby 1.0 (which will of course be based on the wxruby2 code base). Thoughts? Kevin
Kevin Smith wrote:> I now believe that we should call this wxruby 0.9.0. It is newer than > wxruby 0.6.0 (which was never released as a gem, and probably never will > be). It is not yet "1.0" quality. We can cycle through the 0.9.0 > versions until we actually hit wxruby 1.0 (which will of course be based > on the wxruby2 code base). > >I have no problem with that. Roy
Kevin Smith wrote:> Hi all, > > However, there is nothing in the version number that indicates this is a > "preview" "alpha" "buggy" release. >Well, the "9" in the middle is meant to indicate that it''s a development release, not a stable release. And the release notes and FAQ shout this.> The gem version numbering scheme does not allow things like 2.0-pre. >I totally agree that the limitations imposed by rubygems (and also rubyforge?) are unhelpful and that an -alpha or -pre suffix would be much better.> I now believe that we should call this wxruby 0.9.0. It is newer than > wxruby 0.6.0My concern about using 0.9.0 is that it suggests it''s an upgrade path from 0.6.0, which it isn''t yet. It''s not (yet) a superset of the functionality in that release - it''s something different. It''s not as stable yet. It handles strings differently etc. For people that list wxruby as a dependency to other projects (inc me), I think it''s clearer to end users that they should use the same major version. Personally, if I read docs specifying a dependency, I usually assume that a newer release in the same major version series is as good or better.> It is not yet "1.0" quality.Nope - but nor are ruby-1.9 and perl 5.9 cheers alex
On Mon, 2006-08-21 at 20:07 +0100, Alex Fenton wrote:> Kevin Smith wrote: > > I now believe that we should call this wxruby 0.9.0. It is newer than > > wxruby 0.6.0 > My concern about using 0.9.0 is that it suggests it''s an upgrade path > from 0.6.0, which it isn''t yet. It''s not (yet) a superset of the > functionality in that release - it''s something different. It''s not as > stable yet. It handles strings differently etc.I would love to hear other opinions. Here are the options I have seen suggested or can think of: wxruby 0.0.33 Pros: Makes it clear that it''s early alpha Cons: Looks older/worse than wxruby 0.6.0 wxruby 0.9.0 Pros: Clearly immature Cons: Looks newer/better than wxruby 0.6.0 wxruby 1.9.0 Pros: Implies that it is "before 2.0" Cons: Looks very mature and newer/better than wxruby 0.6.0 wxruby2 0.0.33 Pros: Very accurate Cons: People might get confused by wxruby2 vs. wxruby, especially later when we either have wxruby2 1.0 or switch to wxruby 2.0 One debatable point is whether to use the even/odd stable/unstable numbering system. Personally, I strongly dislike it, and it is certainly not used industry-wide. However, it is used by both Ruby and wx. I would be more comfortable with it after we have our first stable release out. Another point of concern for me is just how unstable this release will be. For the larger samples, I am lucky to go 30 seconds before getting a segfault and crashing out. My SpaceMonkeys game always crashes within about 3 seconds. Perhaps it''s worse on Linux than other platforms, but calling that "1.9" seems very misleading to me. Thoughts? Opinions? Other suggestions? Kevin
> wxruby 0.9.0 > Pros: Clearly immature > Cons: Looks newer/better than wxruby 0.6.0I like this one because for me the current wxRuby is much better than 0.6.0 every was, maybe it is because I mostly use OS X. I think we should work toward 1.0.0 during alpha/beta stage and then start calling it: wxRuby 2.6.3.0, wxRuby 2.6.3.1 etc. This is what wxPython does. The first three numbers represent the wxWidgets release number and the fourth is the wxPython release number targeting that wxWidgets release. pros: Easy to see what version of wxWidgets is being used, seems to work fine for wxPython. cons: Messy up until the first initial release. Sean
On Tue, 2006-08-22 at 22:32 -0700, Sean Long wrote:> > wxruby 0.9.0 > > Pros: Clearly immature > > Cons: Looks newer/better than wxruby 0.6.0 > > I like this one because for me the current wxRuby is much better than > 0.6.0 every was, maybe it is because I mostly use OS X.Thanks for your input.> I think we should work toward 1.0.0 during alpha/beta stage and then > start calling it: > wxRuby 2.6.3.0, wxRuby 2.6.3.1 etc. This is what wxPython does. The > first three numbers represent the wxWidgets release number and the > fourth is the wxPython release number targeting that wxWidgets > release. > > pros: Easy to see what version of wxWidgets is being used, seems to > work fine for wxPython. > cons: Messy up until the first initial release.Another con is that gem ONLY allows x.y.z version numbers. So we would not be able to use that scheme within gem. At least, that''s my understanding. Kevin
New proposal for our gem name/version: wxruby2-preview-0.1.0 As long as we are in alpha/preview mode (where the system crashes every few seconds), let''s be up-front and honest about it. Later, when we are near the true release, we can change the gem name from wxruby2-preview to wxruby. At that point, 0.9 or 1.9 could work. The name (wxruby2-preview) clearly distinguishes it from the earlier wxruby 0.6.0. The version number (0.1.0) makes it clear that this is not for production use. Kevin
Kevin Smith wrote:> New proposal for our gem name/version: > > wxruby2-preview-0.1.0 >Sounds good to me. Completeness vis-a-vis 0.6.0 can then be one of our criteria for moving to [01].9 alex
Fine with me. As long as when we update the gem it doesn''t leave the old one hanging around so people accidentally get the wrong one. Roy Kevin Smith wrote:> New proposal for our gem name/version: > > wxruby2-preview-0.1.0 > > As long as we are in alpha/preview mode (where the system crashes every > few seconds), let''s be up-front and honest about it. Later, when we are > near the true release, we can change the gem name from wxruby2-preview > to wxruby. At that point, 0.9 or 1.9 could work. > > The name (wxruby2-preview) clearly distinguishes it from the earlier > wxruby 0.6.0. > > The version number (0.1.0) makes it clear that this is not for > production use. > > Kevin > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > >
Hmmmm. It appears that we could remove the wxruby2-preview gem from rubyforge, and it would no longer be available. But I''m not sure how to handle users who already had it on their system. First, if the tried to upgrade their wxruby2-preview gem, maybe we could replace it with a dummy gem that somehow told them they need to switch to the wxruby gem series? Second, if someone just tried to install wxruby when they already had wxruby2 installed, what would happen? Would gem detect the conflict? What error message would it give? Without a clear migration path, this proposal might not be practical. Kevin On Thu, 2006-08-24 at 14:17 -0400, Roy Sutton wrote:> Fine with me. As long as when we update the gem it doesn''t leave the > old one hanging around so people accidentally get the wrong one. > > Roy > > Kevin Smith wrote: > > New proposal for our gem name/version: > > > > wxruby2-preview-0.1.0 > > > > As long as we are in alpha/preview mode (where the system crashes every > > few seconds), let''s be up-front and honest about it. Later, when we are > > near the true release, we can change the gem name from wxruby2-preview > > to wxruby. At that point, 0.9 or 1.9 could work. > > > > The name (wxruby2-preview) clearly distinguishes it from the earlier > > wxruby 0.6.0. > > > > The version number (0.1.0) makes it clear that this is not for > > production use. > > > > Kevin > > > > > > _______________________________________________ > > wxruby-users mailing list > > wxruby-users at rubyforge.org > > http://rubyforge.org/mailman/listinfo/wxruby-users > > > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users
Kevin Smith wrote:> First, if the tried to upgrade their wxruby2-preview gem, maybe we could > replace it with a dummy gem that somehow told them they need to switch > to the wxruby gem series? >Yes, this would work.> Second, if someone just tried to install wxruby when they already had > wxruby2 installed, what would happen? Would gem detect the conflict? > What error message would it give?Just tested out creating a gem that checks for conflicting previously installed gem versions. It checks, warns with instructions on how to uninstall, and aborts. Looks like it will work for us if we want to pursue this path - we just add something along the lines of the script below to gemspec.extensions. It will be easier if we can have a constant defined that gives the version of the library eg Wx::WXRUBY_VERSION, and perhaps Wx::WXRUBY2 (just defined or not) or Wx::WXRUBY_PREVIEW_VERSION to distinguish the alpha series from the newer ones that will replace it. a ------ require ''rubygems'' begin require ''wx'' # test if the currently installed version is from preview series # if Wx::WXRUBY2 warn "************************************************" warn "Cannot install because an old version is present" warn "Please uninstall first using the command:" warn "# gem uninstall wxruby2-preview" warn "************************************************" # abort installation raise "Cannot install" rescue LoadError # nothingn previously installed, fine to continue with installation end
On Sun, 2006-08-27 at 14:44 +0100, Alex Fenton wrote:> Just tested out creating a gem that checks for conflicting previously > installed gem versions. It checks, warns with instructions on how to > uninstall, and aborts. Looks like it will work for us if we want to > pursue this path - we just add something along the lines of the script > below to gemspec.extensions. > > It will be easier if we can have a constant defined that gives the > version of the library eg Wx::WXRUBY_VERSION, and perhaps Wx::WXRUBY2 > (just defined or not) or Wx::WXRUBY_PREVIEW_VERSION to distinguish the > alpha series from the newer ones that will replace it.Sweet! Thanks for taking this on. With this, I think we have decided to name the gem wxruby-preview, and have an initial version of something like 0.0.34 (depending on exactly when the release happens). Yes, let''s have Wx::WXRUBY_VERSION. I don''t think we''ll need either of the other two, since wxruby 0.6.0 was never a gem, and the preview version will be detectable by a very low version number. Can you submit an actual patch to implement this? Ideally at build time we would pull the latest version number from the README file, but I''ll settle for hard-coding it for now. Kevin
Kevin Smith wrote:> Yes, let''s have Wx::WXRUBY_VERSION....> Can you submit an actual patch to implement this?See attached, adding WXRUBY_VERSION (and also WXWIDGETS_VERSION, if you like). This also updates the packager to use the agreed gem version name and number, and adds a quick test in minimal.rb sample''s About dialog.> Ideally at build time > we would pull the latest version number from the README file, but I''ll > settle for hard-coding it for now.Yes, I would love to find a neat way to do this for other Ruby projects too. Anyone know a sane way? alex -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wx_rb.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060829/049fdefc/attachment.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: minimal_rb.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060829/049fdefc/attachment-0001.pl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: rakepackage_rb.patch Url: http://rubyforge.org/pipermail/wxruby-users/attachments/20060829/049fdefc/attachment-0002.pl
On Tue, 2006-08-29 at 19:56 +0100, Alex Fenton wrote:> See attached, adding WXRUBY_VERSION (and also WXWIDGETS_VERSION, if you > like). > > This also updates the packager to use the agreed gem version name and > number, and adds a quick test in minimal.rb sample''s About dialog.Nice. Applied, thanks.> > Ideally at build time > > we would pull the latest version number from the README file, but I''ll > > settle for hard-coding it for now. > Yes, I would love to find a neat way to do this for other Ruby projects > too. Anyone know a sane way?I think eventually it should be hooked into our VCS tool. I would also like to see the README version numbers include a build date as well. For now, we already have a mess with the version number appearing in about five places. Hopefully over time we can improve the situation, but as I said, I think getting our VCS in place first makes sense. I have tagged 0.0.34, including these VERSION patches, and also the gemspec changes. It does not include your ActivateEvent patch (which I haven''t looked at yet), nor Roy''s big zipfile patches. Kevin