[Rubygems-developers] problems with 1.3.0 non-root autoinstall

Chad Woolley thewoolleyman at gmail.com
Thu Aug 21 16:53:24 EDT 2008

On Thu, Aug 21, 2008 at 1:12 PM, Martin Krauskopf
<martin.krauskopf at gmail.com> 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

More information about the Rubygems-developers mailing list