On 11/12/07, Rick Olson <[EMAIL PROTECTED]> wrote: > > > FYI, this ticket [ http://dev.rubyonrails.org/ticket/10074 ] seeks to > > avoid this issue in the future, and seems to have helped, since the > > new beta gem is 1.99.0. I think 2.0.0.<revision> would have been a > > better choice myself, but oh well :) > > Well then it would've loaded in front of 2.0.0, right? I think that's > why 1.99 was chosen.
Yes, but I proposed incrementing the "TINY" component in the "real" release - so you'd get 2.0.1 as the first final release that you push to RubyForge. This would have the benefit of making the beta release versions more indicitive of what the actual release will be. e.g., 2.0.0.<x> seems closer to 2.0.1 than 1.99.<x> is to 2.0.0. When you refer to "2.0 RC1", it makes sense for the version to start with "2.0". As long as you aren't stuck on having the final release have a zero TINY component, this works fine. I describe this in more detail in the ticket. Regardless, they versioning is now at least sequential with regard to branch/trunk chronology, and doesn't mix branch and trunk versions sequentially, so that's the main point. Thanks for making the change! -- Chad --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
