FAQ
Hello,

Is it possible to have

2.2.1beta1 VERSION, for a perl module?

Kartik Thakore
On 2010-08-04, at 2:21 PM, Guillaume Cottenceau wrote:

On Wed, Aug 4, 2010 at 7:08 PM, Kartik Thakore <thakore.kartik@gmail.com
wrote:
I dont think you can have that version.

What if you did '2.2.1_2' that means a development version.
Sorry, I would really like to say yes, but I've done quite some
packaging work for Mandriva, and honestly this doesn't look like dev
version (it looks awkward actually),
We can ask perl module devel mailing list for help?
If that would help why not :)
Kartik Thakore

On 2010-08-04, at 12:40 PM, Guillaume Cottenceau
wrote:
I of course do.

[gc@meuh /tmp/fb/frozen-bubble] git diff lib/Games/FrozenBubble.pm
diff --git a/lib/Games/FrozenBubble.pm b/lib/Games/FrozenBubble.pm
index b494f36..4bd46e7 100644
--- a/lib/Games/FrozenBubble.pm
+++ b/lib/Games/FrozenBubble.pm
@@ -1,6 +1,6 @@
package Games::FrozenBubble;

-our $VERSION = '2.2.1';
+our $VERSION = '2.2.1beta1';

1;

[gc@meuh /tmp/fb/frozen-bubble] ./Build clean ; perl Build.PL &&
./Build && sudo ./Build install
Cleaning up build files
[Alien::SDL] Testing header(s): iconv.h
[Alien::SDL] Testing header(s): math.h
[Alien::SDL] Testing header(s): SDL.h
[Alien::SDL] Testing header(s): SDL_mixer.h
Creating new 'MYMETA.yml' with configuration results
Can't find dist packages without a MANIFEST file
Run 'Build manifest' to generate one

WARNING: Possible missing or corrupt 'MANIFEST' file.
Nothing to enter for 'provides' field in metafile.
Creating new 'Build' script for 'Games-FrozenBubble' version
'v2.2.1'



On Wed, Aug 4, 2010 at 6:38 PM, Kartik Thakore <thakore.kartik@gmail.com
wrote:
ReRun

perl Build.PL


Kartik Thakore

On 2010-08-04, at 11:18 AM, Guillaume Cottenceau <gcottenc@gmail.com
wrote:
On Wed, Aug 4, 2010 at 1:58 PM, Kartik Thakore
<thakore.kartik@gmail.com>
wrote:
No go ahead and change that. I made a new branch for CPAN.
I'm not able to set the version in your new build system. When I
do that
change

--- a/lib/Games/FrozenBubble.pm
+++ b/lib/Games/FrozenBubble.pm
@@ -1,6 +1,6 @@
package Games::FrozenBubble;

-our $VERSION = '2.2.1';
+our $VERSION = '2.2.1beta1';

1;


the build script still says:

Creating new 'Build' script for 'Games-FrozenBubble' version
'v2.2.1'

additionally, the build breaks server/fb-server.c; e.g. it
replaces
the C string concatenation of VERSION (before your breakage of
e6f581b438c163ce1d9edd932b07dc3caba24987) to the actual version


On Wed, Aug 4, 2010 at 4:35 AM, Guillaume Cottenceau
<gcottenc@gmail.com>
wrote:
On Wed, Aug 4, 2010 at 10:19 AM, Guillaume Cottenceau
wrote:
On Tue, Aug 3, 2010 at 8:04 PM, Kartik Thakore
wrote:
The code is ready for you in Github.
it seems that this fixes the version issue but the other
questions in
actually, it doesn't fully: it fixes the 2.210 => 2.2.1 issue
but it
doesn't additionally mark the beta status in the version (e.g.
for
example 2.2.1beta1). any problem with that?

--
Guillaume Cottenceau - http://zarb.org/~gc/


--
Guillaume Cottenceau - http://zarb.org/~gc/


--
Guillaume Cottenceau - http://zarb.org/~gc/


--
Guillaume Cottenceau - http://zarb.org/~gc/

Search Discussions

  • David Golden at Aug 4, 2010 at 7:14 pm

    On Wed, Aug 4, 2010 at 2:59 PM, Kartik Thakore wrote:
    Hello,

    Is it possible to have

    2.2.1beta1 VERSION, for a perl module?
    It's not advisable.

    C.f. http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/

    David
  • Guillaume Cottenceau at Aug 4, 2010 at 8:12 pm

    On Wed, Aug 4, 2010 at 9:13 PM, David Golden wrote:
    On Wed, Aug 4, 2010 at 2:59 PM, Kartik Thakore wrote:
    Hello,

    Is it possible to have

    2.2.1beta1 VERSION, for a perl module?
    It's not advisable.

    C.f. http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/
    Hum. This is for an application (a game), not a module, and I want it
    to be clearly labelled as a beta release. So fine with "There are no
    standard conventions for alphanumerics, and you just make life hard
    for the machines, which means no help for the humans." but I don't see
    the big problem for machines and I don't know how to say "hey this is
    beta" only with numbers; especially if "5.005_03 is equivalent to
    5.5.30", I don't see how this could be considered to mark it beta/dev
    :/

    Thanks for your help..

    --
    Guillaume Cottenceau - http://zarb.org/~gc/
  • David Golden at Aug 4, 2010 at 8:22 pm

    On Wed, Aug 4, 2010 at 4:12 PM, Guillaume Cottenceau wrote:
    Hum. This is for an application (a game), not a module, and I want it
    to be clearly labelled as a beta release. So fine with "There are no
    standard conventions for alphanumerics, and you just make life hard
    for the machines, which means no help for the humans." but I don't see
    the big problem for machines and I don't know how to say "hey this is
    beta" only with numbers; especially if "5.005_03 is equivalent to
    5.5.30", I don't see how this could be considered to mark it beta/dev
    :/

    Thanks for your help..
    Let me try to clarify. For a given Perl module called "Foo", the
    "$Foo::VERSION" variable defines the version number that the perl
    interpreter will use to check against a minimum required version:

    use Foo 1.02;

    You can't put alphanumerics in $Foo::VERSION and have things behave nicely.

    However, a "distribution" -- by which I mean a tarball containing Perl
    modules, can have any name/number you want.. By convention, it should
    follow the same rules as for Perl module numbers, but it doesn't have
    to. The big downside to alphanumerics is that various CPAN ecosystem
    tools may not know how to interpret it as a "number".

    If you don't plan on releasing this to CPAN, then you don't have to
    worry about it. If you do, then you should be aware of the
    conventions. They evolved organically over time, if that helps
    explain why things are the way they are.

    -- David
  • Kartik Thakore at Aug 4, 2010 at 8:42 pm
    How do we make this work?

    I get a error doing this.

    Kartik Thakore
    On 2010-08-04, at 4:21 PM, David Golden wrote:

    On Wed, Aug 4, 2010 at 4:12 PM, Guillaume Cottenceau <gcottenc@gmail.com
    wrote:
    Hum. This is for an application (a game), not a module, and I want it
    to be clearly labelled as a beta release. So fine with "There are no
    standard conventions for alphanumerics, and you just make life hard
    for the machines, which means no help for the humans." but I don't
    see
    the big problem for machines and I don't know how to say "hey this is
    beta" only with numbers; especially if "5.005_03 is equivalent to
    5.5.30", I don't see how this could be considered to mark it beta/dev
    :/

    Thanks for your help..
    Let me try to clarify. For a given Perl module called "Foo", the
    "$Foo::VERSION" variable defines the version number that the perl
    interpreter will use to check against a minimum required version:

    use Foo 1.02;

    You can't put alphanumerics in $Foo::VERSION and have things behave
    nicely.

    However, a "distribution" -- by which I mean a tarball containing Perl
    modules, can have any name/number you want.. By convention, it should
    follow the same rules as for Perl module numbers, but it doesn't have
    to. The big downside to alphanumerics is that various CPAN ecosystem
    tools may not know how to interpret it as a "number".

    If you don't plan on releasing this to CPAN, then you don't have to
    worry about it. If you do, then you should be aware of the
    conventions. They evolved organically over time, if that helps
    explain why things are the way they are.

    -- David
  • David Golden at Aug 5, 2010 at 12:02 am

    On Wed, Aug 4, 2010 at 4:42 PM, Kartik Thakore wrote:
    How do we make this work?

    I get a error doing this.
    I think you need to be a lot more specific about "this". I'm
    beginning to suspect an XY problem.

    Walk us through -- step by step -- what you're trying to accomplish,
    the steps you're taking, and the "errors" that you're seeing.

    -- David
  • Guillaume Cottenceau at Aug 5, 2010 at 7:20 am

    On Thu, Aug 5, 2010 at 2:02 AM, David Golden wrote:
    On Wed, Aug 4, 2010 at 4:42 PM, Kartik Thakore wrote:
    How do we make this work?

    I get a error doing this.
    I think you need to be a lot more specific about "this".  I'm
    beginning to suspect an XY problem.

    Walk us through -- step by step -- what you're trying to accomplish,
    the steps you're taking, and the "errors" that you're seeing.
    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 :)

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

    --
    Guillaume Cottenceau - http://zarb.org/~gc/
  • David Golden at Aug 5, 2010 at 11:08 am

    On Thu, Aug 5, 2010 at 3:20 AM, Guillaume Cottenceau 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
  • Kartik Thakore at Aug 5, 2010 at 11:46 am
    Kartik Thakore
    On 2010-08-05, at 7:07 AM, David Golden wrote:

    On Thu, Aug 5, 2010 at 3:20 AM, Guillaume Cottenceau <gcottenc@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
  • David Golden at Aug 5, 2010 at 3:55 pm

    On Thu, Aug 5, 2010 at 7:45 AM, Kartik Thakore wrote:
    thia dist_name => in M::B correct?
    Yes.

    Though maybe I should just implement a feature to add '-TRIAL', since
    I'll need that anyway for CPAN Meta 2 support. (Dist::Zilla already
    supports -TRIAL).

    -- David
  • Eric Wilhelm at Aug 5, 2010 at 6:46 pm
    # from David Golden
    # on Thursday 05 August 2010 08:55:
    Though maybe I should just implement a feature to add '-TRIAL', since
    I'll need that anyway for CPAN Meta 2 support.  (Dist::Zilla already
    supports -TRIAL).
    Does search.cpan.org understand "-TRIAL" now? Last I looked, it was
    properly handled (i.e. not indexed) by PAUSE, but would leak through in
    a few other places where it appears that an assumption was being made
    without checking the index.

    It also looked like '-TRIAL' was intended to be used as a pre-release
    without bumping any version numbers, so you could have -TRIAL1,
    -TRIAL2, etc all with the version e.g. 5.6.2. Am I understanding that
    right?

    --Eric
    --
    "It works better if you plug it in!"
    --Sattinger's Law
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • David Golden at Aug 5, 2010 at 7:25 pm

    On Thu, Aug 5, 2010 at 2:46 PM, Eric Wilhelm wrote:
    Does search.cpan.org understand "-TRIAL" now?  Last I looked, it was
    properly handled (i.e. not indexed) by PAUSE, but would leak through in
    a few other places where it appears that an assumption was being made
    without checking the index.
    CPAN::DistnameInfo added support for '-TRIAL' in 0.10 back in March of
    this year and I'm pretty sure that's what Graham is using for
    search.cpan.org.

    It's certainly possible that it's leaking through elsewhere. rjbs has
    been doing -TRIAL releases of Dist::Zilla and may have a better sense
    of where any remaining issues are.
    It also looked like '-TRIAL' was intended to be used as a pre-release
    without bumping any version numbers, so you could have -TRIAL1,
    -TRIAL2, etc all with the version e.g. 5.6.2.  Am I understanding that
    right?
    I believe that was specific to perl distributions, not CPAN
    distributions, but it may work for those as well.

    -- David
  • Kartik Thakore at Aug 5, 2010 at 9:07 pm
    So how can we force the VERSION for the non CPAN release?

    Kartik Thakore
    On 2010-08-05, at 3:24 PM, David Golden wrote:
    On Thu, Aug 5, 2010 at 2:46 PM, Eric Wilhelm wrote:
    Does search.cpan.org understand "-TRIAL" now? Last I looked, it was
    properly handled (i.e. not indexed) by PAUSE, but would leak
    through in
    a few other places where it appears that an assumption was being made
    without checking the index.
    CPAN::DistnameInfo added support for '-TRIAL' in 0.10 back in March of
    this year and I'm pretty sure that's what Graham is using for
    search.cpan.org.

    It's certainly possible that it's leaking through elsewhere. rjbs has
    been doing -TRIAL releases of Dist::Zilla and may have a better sense
    of where any remaining issues are.
    It also looked like '-TRIAL' was intended to be used as a pre-release
    without bumping any version numbers, so you could have -TRIAL1,
    -TRIAL2, etc all with the version e.g. 5.6.2. Am I understanding
    that
    right?
    I believe that was specific to perl distributions, not CPAN
    distributions, but it may work for those as well.

    -- David
  • Kartik Thakore at Aug 5, 2010 at 10:28 pm
    With David's (xdg) help we have come up with a simple solution (which should
    have been more obvious).

    http://github.com/kthakore/frozen-bubble/blob/e5fe8243e67ca552c02099db8f5a274c6171e1b1/lib/Games/FrozenBubble.pm

    Please give that a run. The 'display' version is RELEASE_VERSION.

    Regards,
    Kartik
  • Todd Rinaldo at Aug 4, 2010 at 10:26 pm
    CPAN recognizes "_" in the version variable as indicating a development version. This is easy if you're only releasing regular floating point versions i.e. "2.2" becomes "2.2_01".

    Does this work? I'm not clear on the validity of _ with 2 decimal versions.
    our $VERSION = '2.2.1_01';
    On Aug 4, 2010, at 3:21 PM, David Golden wrote:
    On Wed, Aug 4, 2010 at 4:12 PM, Guillaume Cottenceau wrote:
    Hum. This is for an application (a game), not a module, and I want it
    to be clearly labelled as a beta release. So fine with "There are no
    standard conventions for alphanumerics, and you just make life hard
    for the machines, which means no help for the humans." but I don't see
    the big problem for machines and I don't know how to say "hey this is
    beta" only with numbers; especially if "5.005_03 is equivalent to
    5.5.30", I don't see how this could be considered to mark it beta/dev
    :/

    Thanks for your help..
    Let me try to clarify. For a given Perl module called "Foo", the
    "$Foo::VERSION" variable defines the version number that the perl
    interpreter will use to check against a minimum required version:

    use Foo 1.02;

    You can't put alphanumerics in $Foo::VERSION and have things behave nicely.

    However, a "distribution" -- by which I mean a tarball containing Perl
    modules, can have any name/number you want.. By convention, it should
    follow the same rules as for Perl module numbers, but it doesn't have
    to. The big downside to alphanumerics is that various CPAN ecosystem
    tools may not know how to interpret it as a "number".

    If you don't plan on releasing this to CPAN, then you don't have to
    worry about it. If you do, then you should be aware of the
    conventions. They evolved organically over time, if that helps
    explain why things are the way they are.

    -- David
    Todd Rinaldo
    toddr@cpanel.net
  • Todd Rinaldo at Aug 4, 2010 at 11:53 pm

    On Aug 4, 2010, at 3:12 PM, Guillaume Cottenceau wrote:
    On Wed, Aug 4, 2010 at 9:13 PM, David Golden wrote:
    On Wed, Aug 4, 2010 at 2:59 PM, Kartik Thakore wrote:
    Hello,

    Is it possible to have

    2.2.1beta1 VERSION, for a perl module?
    It's not advisable.

    C.f. http://www.dagolden.com/index.php/369/version-numbers-should-be-boring/
    Hum. This is for an application (a game), not a module, and I want it
    to be clearly labelled as a beta release. So fine with "There are no
    standard conventions for alphanumerics, and you just make life hard
    for the machines, which means no help for the humans." but I don't see
    the big problem for machines and I don't know how to say "hey this is
    beta" only with numbers; especially if "5.005_03 is equivalent to
    5.5.30", I don't see how this could be considered to mark it beta/dev
    :/
    "5.005_03" is a string not a number.
  • Eric Wilhelm at Aug 5, 2010 at 12:06 am
    # from Guillaume Cottenceau
    # on Wednesday 04 August 2010 13:12:
    but I don't see
    the big problem for machines and I don't know how to say "hey this is
    beta" only with numbers; especially if "5.005_03 is equivalent to
    5.5.30", I don't see how this could be considered to mark it beta/dev
    The first problem for machines is that $VERSION is a scalar and has no
    guaranteed structure to it, so you could put any string or whatever you
    want in it. Now when you try to compare that to something, you have to
    compare it as a number, so fun ensues because overloading involves
    objects and ...

    The second problem for machines is when you try to use packaging tools
    that expected a simple number in $VERSION or might try to complain
    about something that doesn't parse as a number.

    If you don't mind angering the machines, put whatever you want in there.

    But, why are humans seeing the raw value of $yourmodule->VERSION anyway?
    If it's an application, present / format it differently. You can still
    store whatever you want in it because it's mostly just a scalar. Might
    be a good idea to find some way to do it with a version.pm object just
    for maintainability.

    Now, for marking releases as Beta on the CPAN, well...

    --Eric
    --
    The reasonable man adapts himself to the world; the unreasonable man
    persists in trying to adapt the world to himself. Therefore all progress
    depends on the unreasonable man.
    --George Bernard Shaw
    ---------------------------------------------------
    http://scratchcomputing.com
    ---------------------------------------------------
  • David Nicol at Aug 5, 2010 at 9:11 pm
    It appears that your use case -- you want to publish the beta version
    on CPAN without having the non-beta-testers get it too -- is not
    supported by xdg's essay.

    I see two possible approaches:

    1: leapfrogging. Release the beta versions with version numbers that
    are less than the latest release version. This approach might require
    some planning, possibly including bumping the version number on the
    current stable to make space. The beta testers will have to jump
    through something of a hoop, depending on their tools and skill with
    them, so you'll have to support them in that.

    2: release beta versions in an entirely separate name-space, so
    instead of having the beta after Awesome::Application 3.003 having
    confusing version number just call it Awesome::Application_betatest
    3.004 and let them coexist. Some research may be required to figure
    out the best way to do that -- you don't want CPAN.pm pulling in the
    Betatest version of something unreleased because it includes something
    that it thinks is a proper upgrade, for instance. The additional
    end-user control over what code is participating in the testing, for
    a module, with less risk, could be good, too, for a module.
  • Kartik Thakore at Aug 5, 2010 at 9:20 pm
    Kartik Thakore
    On 2010-08-05, at 5:11 PM, David Nicol wrote:

    It appears that your use case -- you want to publish the beta version
    on CPAN without having the non-beta-testers get it too -- is not
    supported by xdg's essay.
    I dont know where you are getting this from.

    Suppose I have a Module::Build module that I never ever want to put on
    CPAN. How do I force the our $VERSION to be non numeric.

    I see two possible approaches:

    1: leapfrogging. Release the beta versions with version numbers that
    are less than the latest release version. This approach might require
    some planning, possibly including bumping the version number on the
    current stable to make space. The beta testers will have to jump
    through something of a hoop, depending on their tools and skill with
    them, so you'll have to support them in that.
    No. Nothing to do with CPAN. 'non-CPAN'.
    2: release beta versions in an entirely separate name-space, so
    instead of having the beta after Awesome::Application 3.003 having
    confusing version number just call it Awesome::Application_betatest
    3.004 and let them coexist. Some research may be required to figure
    out the best way to do that -- you don't want CPAN.pm pulling in the
    Betatest version of something unreleased because it includes something
    that it thinks is a proper upgrade, for instance. The additional
    end-user control over what code is participating in the testing, for
    a module, with less risk, could be good, too, for a module.
    'non-CPAN'

    regards,
    Kartik

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmodule-authors @
categoriesperl
postedAug 4, '10 at 6:59p
activeAug 5, '10 at 10:28p
posts19
users6
websitecpan.org...

People

Translate

site design / logo © 2018 Grokbase