On Thu, Aug 21, 2008 at 1:12 PM, Martin Krauskopf <[EMAIL PROTECTED]> wrote: > If next stable release is supposed to be 1.3.0 then trunk can't be > 1.3.0.dev. It must be >1.2.0 & <1.3.0. So 1.2.0.rev seems to be more correct > then 1.3.0.dev.
Right, if you insist on making the public releases end in zero. However, I'm proposing that the initial *public* release always be x.x.1, not x.x.0. > Such apps should not make such assumption, I think. Since trunk might become > e.g. 2.0. So they should rather based the logic on the released version vs. > the '>latest_stable_release' version, i.e. trunk. So current 1.2.0.rev works > well. It depends whether the project maintains a bugfix branch for the current release, such as Rails does. In that case, the feature you are depending on may only be in 1.3.0 edge version, but not in the 1.2.1 bugfix version. That means that your check for using the feature needs to be >= 1.3.0, not > 1.2.0. Now, rubygems doesn't usually do emergency bugfix releases. However, if there is ever the situation where the trunk (which is intended to be 1.3.0) is unreleasable, and there needs to be an emergency release (1.2.1) from a branch off the prior release (1.2.0), then having the trunk incremented to the next minor version (1.3.0) would make sense. -- Chad _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
