On Thu, Aug 5, 2010 at 3:20 AM, Guillaume Cottenceau <gcott...@gmail.com> wrote:
> Kartik and friends rewrote SDL_perl (a Perl module with SDL bindings)
> using a different API. Then they ported my Perl-based game to using
> that new Perl module, and to be CPAN-friendly. My game previous
> versions were 2.0.0, 2.1.0, 2.2.0, so now I would like it to be
> versioned 2.2.1. But prior to that, I would like to release a beta
> version because I suspect a couple of corner cases to contain bugs. So
> we're looking for a way to version it 2.2.1-beta1 or something
> similar, in order for it to NOT be included in stable distributions or
> replace 2.2.0 for regular users. Then we'll release 2.2.1 in a couple
> of weeks when no more important bugs are known.
>
> Thanks for your patience :)

Let me restate what I think the situation is:

* Frozen Bubble is now (or will be) a CPAN distribution rather than a
standalone program distributed independently

* You would like the CPAN version to indicate a "beta" status so that
OS packagers don't blindly replace it for users

I don't know exactly what criteria OS packagers use for deciding what
is or isn't beta, but presumably the tarball name is significant.
They may or may not be Perl experts familiar with CPAN conventions.

I would suggest the following:

* To be consistent with your prior versioning (dotted-decimal),
require a minimum version of Perl that understands "v1.2.3" numbering.
That means 5.6.0 at a minimum, 5.8.1 is better, 5.10.0 is best but you
might not want to impose that requimrent on end-users.

* For the *modules* inside the distribution, follow CPAN conventions
and include an underscore in the version number within the modules if
they are beta  e.g.

    our $VERSION = v2.2_1

Your final release should bump the last number and use a decimal

    our $VERSION = v2.2.2

(For the sake of simplicity and compatibility with Perl < 5.10.0, I
suggest that you NOT use the version.pm module.)

* For the *distribution* (i.e. the tarball) you have more choices.
For Perl people it would be sufficient to have this:

    Frozen-Bubble-v2.2_1.tar.gz

But for people unfamiliar with CPAN conventions, I suggest one of the following:

    a) Frozen-Bubble-beta-v2.2_1.tar.gz
    b) Frozen-Bubble-v2.2_1-TRIAL.tar.gz
    c) Frozen-Bubble-v2.2.1-TRIAL.tar.gz

In (a), you put "beta" in the "title" of the distribution, but leave
the underscore in the version number. This tells PAUSE (the CPAN
indexer) not to index this distribution, which is what you want for a
beta.  You might confuse some parts of the ecosystem like CPAN
Testers, which will think that "Frozen-Bubble" is a different
distribution than "Frozen-Bubble-beta", but that's a fairly small
price to pay.

The (b) and (c) forms are not very common and take advantage of a
little-known feature of PAUSE.  Appending "-TRIAL" to the version
number is another way of telling PAUSE not to index the distribution.
If you do that, you have the choice of (b) or (c) as the underscore is
no longer significant in the tarball name.  Hopefully, that is also
enough to warn off packagers.

* If you accept "-TRIAL" as the answer that gives you a tarball name
that packagers will know not to distribute and are consistent in
always using it for your betas, then you could even stop using an
underscore in the $VERSION variable and just use a period.

    our $VERSION = v2.2.1;

* Just as a reminder, you still always want to bump the version
numbers of your modules as you go from beta to final.  CPAN
conventions don't really support the concept of "2.2.1-beta" followed
by "2.2.1" (final).  Numbers are expected to be monotonically
increasing.  You might want to adopt your own convention of odd
numbers being development/beta and even numbers being releases.

That's probably far more complex that you ever imagined, but I hope it
gives you some useful direction.  As I said in my article, it's really
too bad that version numbers aren't boring.

Thank you for writing such a cool game in Perl!

> PS: is an XY problem bound to a specific gender? do you think giving
> the problem to an XX person would solve it faster? :)

The "XY problem" refers to wanting to do "X", thinking "Y" is the
right approach and asking how to do "Y", but "X" is vital context and
people might have better solutions than just "Y".  c.f.
http://www.perlmonks.org/index.pl?node_id=542341

-- David

Reply via email to