Kartik Thakore
On 2010-08-05, at 7:07 AM, David Golden <xda...@gmail.com> wrote:
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
Yes.
* You would like the CPAN version to indicate a "beta" status so that
OS packagers don't blindly replace it for users
No, only the one on the main site. CPAN already has a differing
versions.
2.111 on CPAN is 2.1.1beta1 for gc's os releases.
The problem we are having is we cant force a non numerical VERSION in
M::B for the non CPAN release.
Our code uses the VERSION to compile a fb-server with output saying
what version it is. This is why we need it in VERSION.
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
This makes sense too.
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.
thia dist_name => in M::B correct?
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
Thank you so much for lots of cool things in Perl :)
-- David
Kartik
