vassalengine-devel Mailing List for VASSAL Engine

Thus spake Michael Kiefte:
> 
> >
> > I have a particular objection against F#, namely that I don't want to
> > use a language tied to a company. I've had enough of that with Java.
> >
> 
> That's a shame, because I am a serious MATLAB guru. My second choice is
> LabVIEW.  I've already got the real-time VM for VASSAL working on dedicated
> hardware with a 2 MHz TI DSP.  You can even pick it up on FM radio if you
> can convert modulated noises into VASSAL commands in your head.

Ha.
 
> I once programmed a speech synthesizer entirely in PostScript. (That is,
> sadly, true.) So.... If we convert VASSAL to PostScript, I'm your man. It's
> just like programming in assembler except you're still allowed to bathe and
> brush your teeth occasionally.

I, too, have coded in PostScript. Hideous language, that.

-- 
J.

>
> I have a particular objection against F#, namely that I don't want to
> use a language tied to a company. I've had enough of that with Java.
>

That's a shame, because I am a serious MATLAB guru. My second choice is
LabVIEW.  I've already got the real-time VM for VASSAL working on dedicated
hardware with a 2 MHz TI DSP.  You can even pick it up on FM radio if you
can convert modulated noises into VASSAL commands in your head.

I once programmed a speech synthesizer entirely in PostScript. (That is,
sadly, true.) So.... If we convert VASSAL to PostScript, I'm your man. It's
just like programming in assembler except you're still allowed to bathe and
brush your teeth occasionally.

Otherwise, I'm cool with C++.

- M.

Thus spake Wojciech Meyer:
> >
> > It looks like we're going to have a mixture of C++ and Python.
> >
> 
> I can understand reasons, however..
> I will ask, why not to go for some O'Caml or even F# (mono
> implementation on Linux is fine).  I would like to see VASSAL being
> written in some cleaner language than C++ (and yet as efficient).
> Anyway, I quite liked C++ in past better than Java and I hope it's not a
> mistake.. If C++ project has some rigoruous coding standards and coding
> practices specified upfront (how to do things, what not to do, which
> subset of features we use etc.)  it makes C++ a bit nicer. (LLVM is the
> example on top of my head).

I have a particular objection against F#, namely that I don't want to
use a language tied to a company. I've had enough of that with Java.

Generally, I think it's a bad idea to adopt a language that none of the
core developers have ever used before. With C++ and Python, we have some
experience to draw on while the rest of us are learning.

-- 
J.

On Thu, Jul 21, 2011 at 10:16 PM, Joel Uckelman <uck...@no...> wrote:

> Thus spake Don Lazov:
> >
> > Thank you. So your going to be moving away from using java for VASSAL 4?
> Whic
> > h language are you going in?
> >
>
> It looks like we're going to have a mixture of C++ and Python.
>

I can understand reasons, however..
I will ask, why not to go for some O'Caml or even F# (mono
implementation on Linux is fine).  I would like to see VASSAL being
written in some cleaner language than C++ (and yet as efficient).
Anyway, I quite liked C++ in past better than Java and I hope it's not a
mistake.. If C++ project has some rigoruous coding standards and coding
practices specified upfront (how to do things, what not to do, which
subset of features we use etc.)  it makes C++ a bit nicer. (LLVM is the
example on top of my head).

Mine two cents,
Wojciech


> --
> J.
>
>
> ------------------------------------------------------------------------------
> 5 Ways to Improve & Secure Unified Communications
> Unified Communications promises greater efficiencies for business. UC can
> improve internal communications as well as offer faster, more efficient
> ways
> to interact with customers and streamline customer service. Learn more!
> http://www.accelacomm.com/jaw/sfnl/114/51426253/
> _______________________________________________
> vassalengine-devel mailing list
> vas...@li...
> https://lists.sourceforge.net/lists/listinfo/vassalengine-devel
>

Thus spake Don Lazov:
> 
> Thank you. So your going to be moving away from using java for VASSAL 4? Whic
> h language are you going in? 
>

It looks like we're going to have a mixture of C++ and Python. 

-- 
J.

On Thu, Jul 21, 2011 at 9:26 PM, Don Lazov <dl...@co...> wrote:

> Joel,
>
> Thank you. So your going to be moving away from using java for VASSAL 4?
> Which language are you going in?
>

I'm curious as well,

Wojciech


>
> Best Regards~
> Don
>
> ------------------------------
> *From: *"Joel Uckelman" <uck...@no...>
> *To: *"developers' list for VASSAL" <
> vas...@li...>
> *Sent: *Thursday, July 21, 2011 3:00:52 PM
> *Subject: *Re: [vassalengine-devel] New to Java + Eclipse, SVN & CVS
>
>
> Thus spake Don Lazov:
> >
> > Greetings,
> >
> > I am finally now making the transition (work wise) to java. At work we
> use ja
> > va and eclipse.
>
> I should warn you that we're planning to move in the other direction,
> away from Java, for VASSAL 4.
>
> > To learn more about java and CVS & SVN I downloaded a SVN cli
> > ent (tortoise). when I try to bring down VASSAL engine I am getting this
> erro
> > r:
> >
> > svn: Can't open file
> 'vassalengine\VASSAL-src\branches\uckelman-dice\doc\Refe
> > renceManual\images\.svn\tmp\text-base\shapeitem.png.svn-base': The system
> can
> > not find the file specified.
>
> I can't tell you why you're getting that particular error, but it
> appears that you are checking out the whole repository (I suppose you
> must be doing that, as there'd be no particular reason for you to check
> out an outdated branch like that one).
>
> Try checking out a particular branch (something inside VASSAL-src/branches)
> instead.
>
> > I have svn down some smaller projects (and two medium sized ones) and at
> the
> > end (via cmd prompt) it tells me which version was checked out.
>
> We're also planning to move from svn to git for V4...
>
> > I'd like to 1) learn how vassal (and vasl in particular) works via java
> 2) le
> > arn how to better use eclipse and svn+cvs 3) eventually help out some
> maybe o
> > n this project.
> >
> > Is there any kind of documentation or could someone mentor me on how
> after yo
> > u bring down the latest cut to make sure it complies in eclipse?
>
> http://www.vassalengine.org/wiki/Eclipse_setup
>
> --
> J.
>
>
> ------------------------------------------------------------------------------
> 5 Ways to Improve & Secure Unified Communications
> Unified Communications promises greater efficiencies for business. UC can
> improve internal communications as well as offer faster, more efficient
> ways
> to interact with customers and streamline customer service. Learn more!
> http://www.accelacomm.com/jaw/sfnl/114/51426253/
> _______________________________________________
> vassalengine-devel mailing list
> vas...@li...
> https://lists.sourceforge.net/lists/listinfo/vassalengine-devel
>
>
> ------------------------------------------------------------------------------
> 5 Ways to Improve & Secure Unified Communications
> Unified Communications promises greater efficiencies for business. UC can
> improve internal communications as well as offer faster, more efficient
> ways
> to interact with customers and streamline customer service. Learn more!
> http://www.accelacomm.com/jaw/sfnl/114/51426253/
> _______________________________________________
> vassalengine-devel mailing list
> vas...@li...
> https://lists.sourceforge.net/lists/listinfo/vassalengine-devel
>
>

Joel, 

Thank you. So your going to be moving away from using java for VASSAL 4? Which language are you going in? 

Best Regards~ 
Don 

----- Original Message -----
From: "Joel Uckelman" <uck...@no...> 
To: "developers' list for VASSAL" <vas...@li...> 
Sent: Thursday, July 21, 2011 3:00:52 PM 
Subject: Re: [vassalengine-devel] New to Java + Eclipse, SVN & CVS 

Thus spake Don Lazov: 
> 
> Greetings, 
> 
> I am finally now making the transition (work wise) to java. At work we use ja 
> va and eclipse. 

I should warn you that we're planning to move in the other direction, 
away from Java, for VASSAL 4. 

> To learn more about java and CVS & SVN I downloaded a SVN cli 
> ent (tortoise). when I try to bring down VASSAL engine I am getting this erro 
> r: 
> 
> svn: Can't open file 'vassalengine\VASSAL-src\branches\uckelman-dice\doc\Refe 
> renceManual\images\.svn\tmp\text-base\shapeitem.png.svn-base': The system can 
> not find the file specified. 

I can't tell you why you're getting that particular error, but it 
appears that you are checking out the whole repository (I suppose you 
must be doing that, as there'd be no particular reason for you to check 
out an outdated branch like that one). 

Try checking out a particular branch (something inside VASSAL-src/branches) 
instead. 

> I have svn down some smaller projects (and two medium sized ones) and at the 
> end (via cmd prompt) it tells me which version was checked out. 

We're also planning to move from svn to git for V4... 

> I'd like to 1) learn how vassal (and vasl in particular) works via java 2) le 
> arn how to better use eclipse and svn+cvs 3) eventually help out some maybe o 
> n this project. 
> 
> Is there any kind of documentation or could someone mentor me on how after yo 
> u bring down the latest cut to make sure it complies in eclipse? 

http://www.vassalengine.org/wiki/Eclipse_setup 

-- 
J. 

------------------------------------------------------------------------------ 
5 Ways to Improve & Secure Unified Communications 
Unified Communications promises greater efficiencies for business. UC can 
improve internal communications as well as offer faster, more efficient ways 
to interact with customers and streamline customer service. Learn more! 
http://www.accelacomm.com/jaw/sfnl/114/51426253/ 
_______________________________________________ 
vassalengine-devel mailing list 
vas...@li... 
https://lists.sourceforge.net/lists/listinfo/vassalengine-devel 

Thus spake Don Lazov:
> 
> Greetings, 
> 
> I am finally now making the transition (work wise) to java. At work we use ja
> va and eclipse.

I should warn you that we're planning to move in the other direction,
away from Java, for VASSAL 4.

> To learn more about java and CVS & SVN I downloaded a SVN cli
> ent (tortoise). when I try to bring down VASSAL engine I am getting this erro
> r: 
> 
> svn: Can't open file 'vassalengine\VASSAL-src\branches\uckelman-dice\doc\Refe
> renceManual\images\.svn\tmp\text-base\shapeitem.png.svn-base': The system can
> not find the file specified. 

I can't tell you why you're getting that particular error, but it
appears that you are checking out the whole repository (I suppose you
must be doing that, as there'd be no particular reason for you to check
out an outdated branch like that one).

Try checking out a particular branch (something inside VASSAL-src/branches)
instead.
 
> I have svn down some smaller projects (and two medium sized ones) and at the 
> end (via cmd prompt) it tells me which version was checked out. 

We're also planning to move from svn to git for V4...
 
> I'd like to 1) learn how vassal (and vasl in particular) works via java 2) le
> arn how to better use eclipse and svn+cvs 3) eventually help out some maybe o
> n this project. 
> 
> Is there any kind of documentation or could someone mentor me on how after yo
> u bring down the latest cut to make sure it complies in eclipse? 

http://www.vassalengine.org/wiki/Eclipse_setup
 
-- 
J.

Greetings, 

I am finally now making the transition (work wise) to java. At work we use java and eclipse. To learn more about java and CVS & SVN I downloaded a SVN client (tortoise). when I try to bring down VASSAL engine I am getting this error: 

svn: Can't open file 'vassalengine\VASSAL-src\branches\uckelman-dice\doc\ReferenceManual\images\.svn\tmp\text-base\shapeitem.png.svn-base': The system cannot find the file specified. 

I have svn down some smaller projects (and two medium sized ones) and at the end (via cmd prompt) it tells me which version was checked out. 

I'd like to 1) learn how vassal (and vasl in particular) works via java 2) learn how to better use eclipse and svn+cvs 3) eventually help out some maybe on this project. 

Is there any kind of documentation or could someone mentor me on how after you bring down the latest cut to make sure it complies in eclipse? 

On my test projects in eclipse I have been tryiing to import in the projects I svn down by directory, not sure if this is the standard or not. 

Any help, tips, etc. would be welcome for this newbie java/eclipse developer. 

Best Regards~ 
Don 

I added an "Import Module" button to the "Module Design" box in the
VASSAL spash screen thing.  I then extended the LoadModuleAction
class.  That seemed like the most natural thing to do.

- Michael.

On 21/12/2007, Joel Uckelman <uck...@no...> wrote:
> Thus spake "Rodney Kinney":
> >
> > If the code works in 80% of the cases, it doesn't have to be pretty.  We
> > should get it into SVN and make and put it up on the wiki as an executable
> > jar.
> >
> > rk
>
> Maybe we could add an "Import..." menu option somewhere? Eventually
> we'll want to be able to import Cyberboard and ZunTzu modules, too.
>
> --
> J.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> vassalengine-devel mailing list
> vas...@li...
> https://lists.sourceforge.net/lists/listinfo/vassalengine-devel
>


-- 
Michael Kiefte, Ph.D.
Associate Professor
School of Human Communication Disorders
Dalhousie University
Halifax, Nova Scotia, Canada
tel: +1 902 494 5150
fax: +1 902 494 5151

Thus spake "Rodney Kinney":
> 
> If the code works in 80% of the cases, it doesn't have to be pretty.  We
> should get it into SVN and make and put it up on the wiki as an executable
> jar.
> 
> rk

Maybe we could add an "Import..." menu option somewhere? Eventually
we'll want to be able to import Cyberboard and ZunTzu modules, too.

-- 
J.

> I have an almost complete module that imports an ADC2 module into
> VASSAL.


Pretty cool!  I never thought we'd see any such utility get close to
usable.  I'd say we should definitely make this available.

The good thing about spitting out a VASSAL module is that you don't have to
work through all the nit picky cases.  You may already have reached the
point of diminishing returns.  If you can save people the bulk of the work,
they can add finishing touches in the VASSAL editor and they'll still thank
you.  The key is to handle possible errors so that strange input from ADC
just results in some missing components and doesn't make the whole program
fall over.

If the code works in 80% of the cases, it doesn't have to be pretty.  We
should get it into SVN and make and put it up on the wiki as an executable
jar.

rk

> Wouldn't it make more sense to have it spit out a VASSAL module, since
> clearly you can read enough of the ADC2 file to do that?

The short answer is that it does that already. What happens is that
you click on "Import", it asks you which zoom level it is that you
want to import (they're totally separate entities in ADC2), and it
opens with the editor with a completely implemented VASSAL module
based on the contents of the ADC2 files. In particular, if you're not
on a Windows computer, it might ask you about the locations of certain
files, but it tries to make educated guesses that should work most of
the time.

Then you can change whatever you want.

> (I'm planning to make something which does exactly that for Cyberboard
> gameboxes as soon as the source is public.)

Since ADC2 will probably never been open source, I went ahead and
reversed the file formats.

That being said, I might have some insight on how to import a module
in general, so I could help out with that if you like.  VASSAL wasn't
well set up for that, but the solution was to emulate the behaviour of
the XML reading routines in many cases. There may have been other
solutions, but I really didn't want to go changing a lot of already
existing code. Also, making the routines platform independent was a
little tricky especially where filenames were concerned. ADC2 expects
certain files to be in very exact paths of the form C:\ADC2\ etc...
I've got a number of kludges to address that.  Works out fine most of
the time.

Right now, the code is huge, ugly, and largely unreadable. In
addition, I'm sure there's many ADC2 modules out there that will make
it throw nasty exceptions. It could probably go in the experimental
branch though (it's only one .java file and does not rely on
modifications to any other code).

- M.

Thus spake "Michael Kiefte":
> I have an almost complete module that imports an ADC2 module into
> VASSAL.  So far, it is capable of rendering maps made up of discrete
> elements (hexes, hexsides, hexlines, etc.) as well as maps that are
> made up of sheets.  It does hex numbering correctly and renders
> counters correctly as well.  It also does a separate counter tray that
> better mimics the behaviour of the ADC force pools. There are a number
> of things it does not do yet and there are a few quirks still. It
> actually renders maps made of discrete elements substantially better
> than the original program (except for scanned maps, which look exactly
> the same).
> 
> You can compare these two screenshots:
> http://myweb.dal.ca/mkiefte/adc2.png
> http://myweb.dal.ca/mkiefte/vassal.png
> 
> The reason I did this is because it is excruciatingly difficult to get
> my 64-bit Linux machine to run ADC2 (I did get it to work
> eventually--but not before I wrote the module).  It will run all of
> the ADC2 modules that I have, so it makes me happy at least.
> 
> With respect to copyright, my intention was not to write a converter,
> but rather something that just read in an ADC2 file such that it would
> operate correctly.  It does that.
> 
> The problem is that the improvements to this module are coming more
> and more slowly.  I've got the bulk of the information in ADC2 files
> into VASSAL, but it's the little stupid bits that are starting to take
> a lot of time to translate into VASSAL functionality.  If I try to
> complete this module, it will bog me down for a significant amount of
> time.
> 
> What do you guys think?  Should I try to tidy this up for public consumption?
> 
> - Michael.

That's great!

Wouldn't it make more sense to have it spit out a VASSAL module, since
clearly you can read enough of the ADC2 file to do that?

(I'm planning to make something which does exactly that for Cyberboard
gameboxes as soon as the source is public.)

-- 
J.

I have an almost complete module that imports an ADC2 module into
VASSAL.  So far, it is capable of rendering maps made up of discrete
elements (hexes, hexsides, hexlines, etc.) as well as maps that are
made up of sheets.  It does hex numbering correctly and renders
counters correctly as well.  It also does a separate counter tray that
better mimics the behaviour of the ADC force pools. There are a number
of things it does not do yet and there are a few quirks still. It
actually renders maps made of discrete elements substantially better
than the original program (except for scanned maps, which look exactly
the same).

You can compare these two screenshots:
http://myweb.dal.ca/mkiefte/adc2.png
http://myweb.dal.ca/mkiefte/vassal.png

The reason I did this is because it is excruciatingly difficult to get
my 64-bit Linux machine to run ADC2 (I did get it to work
eventually--but not before I wrote the module).  It will run all of
the ADC2 modules that I have, so it makes me happy at least.

With respect to copyright, my intention was not to write a converter,
but rather something that just read in an ADC2 file such that it would
operate correctly.  It does that.

The problem is that the improvements to this module are coming more
and more slowly.  I've got the bulk of the information in ADC2 files
into VASSAL, but it's the little stupid bits that are starting to take
a lot of time to translate into VASSAL functionality.  If I try to
complete this module, it will bog me down for a significant amount of
time.

What do you guys think?  Should I try to tidy this up for public consumption?

- Michael.

Ah ok.  What would really help is having the database do all of the collation using a (more) sophisticated query;  So the final data to be displayed in the Server window would simply be the records returned to the script from that query.  It's generally a good idea to have the DB do as much of the data crunching as possible.

So yeah, I guess the script needs to be made more efficient as you said  :)

-----Original message-----
From: "Rodney Kinney" rod...@co...
Date: Fri, 21 Dec 2007 07:13:30 +1100
To: "developers' list for VASSAL" vas...@li...
Subject: Re: [vassalengine-devel] stable and unstable releases

> Actually, I described a previous version of the Connection History link.
> The current script does store and query MySQL for the connection history.
> The script periodically deletes rows older than a month and returns the
> entire list when asked for the history.  Because it's always pulling all of
> the rows from the table, an index wouldn't help.  I suspect that most of
> time is spent on the client side collating all of the data.
> 
> rk
> 
> 

Actually, I described a previous version of the Connection History link.
The current script does store and query MySQL for the connection history.
The script periodically deletes rows older than a month and returns the
entire list when asked for the history.  Because it's always pulling all of
the rows from the table, an index wouldn't help.  I suspect that most of
time is spent on the client side collating all of the data.

rk

Ah ok;  So it's doing the equivalent of a full table scan and parsing every row of the file?  How big does the text file get?  I'm just curious more than anything, probably no quick fix in that case.


> The information isn't in a database.  The server reports status to a cgi
> script on the web site, which writes the information to a flat file.  The
> connection history is retrieved via another cgi script, which filters the
> information and purges old information.  I'll bet that second script could
> be made more efficient.
> 
> rk
> 
> 

> The Server Status screen takes some time to appear and it's a fairly
> consistent delay.  I was wondering if maybe you're using a mySQL database or
> something similar?  If so, it could be an indexing issue.


The information isn't in a database.  The server reports status to a cgi
script on the web site, which writes the information to a flat file.  The
connection history is retrieved via another cgi script, which filters the
information and purges old information.  I'll bet that second script could
be made more efficient.

rk

Rodney, a quick question.

The Server Status screen takes some time to appear and it's a fairly consistent delay.  I was wondering if maybe you're using a mySQL database or something similar?  If so, it could be an indexing issue.

-----Original message-----
From: "Rodney Kinney" rod...@co...
Date: Thu, 20 Dec 2007 03:13:44 +1100
To: "developers' list for VASSAL" vas...@li...
Subject: Re: [vassalengine-devel] stable and unstable releases

> > That is, 3.0b8 < 3.1.0 successfully. 3.0b8 < 3.0 will fail, but we
> > don't need to be able to do that.
> >
> 
> You're right.
> 
> rk
> 
> 

> That is, 3.0b8 < 3.1.0 successfully. 3.0b8 < 3.0 will fail, but we
> don't need to be able to do that.
>

You're right.

rk

Thus spake "Rodney Kinney":
> 
> > E.g.: 3.0.15 < 3.1.0-svn2708 < 3.1.0-beta1 < 3.1.0-rc3 < 3.1.0
> 
> 
> This ordering makes sense to me.  The new code should also be able to parse
> the old format for beta versions,
> e.g. 3.0b8 < 3.0
> 
> rk

I thought we said that one of the versions being compared will always
be the verision of VASSAL doing the comparison. In that case, whenever
two version strings are compared with this code, at least one will
always have a version number of 3.1.0 or greater; my algorighm stops
parsing as soon as there's enough information to decide the ordering,
so the 'b8' part (which would be considered invalid, if the parser got
that far) is never read.

That is, 3.0b8 < 3.1.0 successfully. 3.0b8 < 3.0 will fail, but we
don't need to be able to do that.

-- 
J.

> E.g.: 3.0.15 < 3.1.0-svn2708 < 3.1.0-beta1 < 3.1.0-rc3 < 3.1.0


This ordering makes sense to me.  The new code should also be able to parse
the old format for beta versions,
e.g. 3.0b8 < 3.0

rk

Thus spake Joel Uckelman:
> 
> Follow-up: 
> 
> Here's what I implemented in 3.1.0-svn2708:
> 
> The version string has two parts: The version number, and the (optional)
> version tag. The version number is a series of period-seperated nonnegative
> integers. The version tag is of the form '-(svn|beta|rc)\d+'.
> 
> The higher-order parts of the version string are on the left. Version
> numbers are ordered how you'd expect. E.g. 3.0.1 < 3.0.10 < 3.1.0.
> Tags are significant only if two version strings have the same version
> number.
> 
> Translate a tag into ingeters as folows: 
> 
> -    --> -1
> svn  -->  0
> beta -->  1
> rc   -->  2
> \d+  -->  itself
> 
> This ensures the following order: If two version have the same version
> number, but one has a tag and the other doesn't, the tagless one is later;
> and svn < beta < rc.
> 
> E.g.: 3.0.15 < 3.1.0-svn2708 < 3.1.0-beta1 < 3.1.0-rc3 < 3.1.0 
> 
> Comments?
>

I found a bug. Minor revision:

The end-of-string is mapped to -1, and the tag hyphen is mapped to -2.

That gives the correct ordering between full releases and releases with
tags.
 
-- 
J.

Thus spake Joel Uckelman:
> Thus spake "Rodney Kinney":
> > 
> > > Just to be clear: The requirement is that version v0 of VASSAL be able
> > > to correctly order any two versions v1, v2 where at most one of v1 and v2
> > > are after v0, yes? Or do we need it to be the case that, say, VASSAL 2.8.
> 3
> > > ,
> > > can tell which of 3.4.9-rc10 and 7.6.4.2-svn7650 is earlier?
> > 
> > 
> > The requirement is that for any version vN after version v0, that v0 be abl
> e
> > to tell that vN is > v0.
> > 
> > rk
> > 
> 
> Ok, then we have a lot more flexibility than I thought.
> 
> Info.compareVersions("3.0.13", X) will return -1 so long as the leading
> part of the version is 3.0.14 or greater. That means past practice doesn't
> constrain us beyond having major.minor.micro-style numbers for the leading
> part, since the first three parts will always be decisive w/r/t any verison
> 3.0.13 or before. All we have to do is make sure that compareVersions()
> knows how to order anything new we introduce.
> 
> So, here's what I propose:
> 
>   X.Y.Z-svnRRRR for current builds from the trunk
>   
>   X.Y.Z-bN for betas
> 
>   X.Y.Z for stable releases
> 
> where the ordering is
> 
>   svn < beta < stable
> 
> for the same X.Y.Z, and within svn and beta, higher numbers are later.
> 
> This is pretty close to what we have now. (Maybe we don't even need
> a designation for betas? They could just be regular releases that don't
> move from testing to stable.)
>

Follow-up: 

Here's what I implemented in 3.1.0-svn2708:

The version string has two parts: The version number, and the (optional)
version tag. The version number is a series of period-seperated nonnegative
integers. The version tag is of the form '-(svn|beta|rc)\d+'.

The higher-order parts of the version string are on the left. Version
numbers are ordered how you'd expect. E.g. 3.0.1 < 3.0.10 < 3.1.0.
Tags are significant only if two version strings have the same version
number.

Translate a tag into ingeters as folows: 

-    --> -1
svn  -->  0
beta -->  1
rc   -->  2
\d+  -->  itself

This ensures the following order: If two version have the same version
number, but one has a tag and the other doesn't, the tagless one is later;
and svn < beta < rc.

E.g.: 3.0.15 < 3.1.0-svn2708 < 3.1.0-beta1 < 3.1.0-rc3 < 3.1.0 

Comments?

-- 
J.
-- 
J.