Re: lynx-dev FWD: Submissions for `dev1'

[Klaus Weide]

On Wed, 31 May 2000, Webmaster Jim wrote:

> Unfortunately I have not had the spare cycles lately to straighten this
> out. Can someone take a look at the Translation Project standards and
> help me set up a re-package of the Lynx tar file so that the robot can
> be happy?

Don't repackage, if that's not really necessary.

The robot doesn't look at tar files anyway AFAIK.

> ------

F. Pinard:
> Hello, Lynx people.
> 
> I just noticed that the Translation Project robot received a few submissions
> for either `Lynx-2.8.4dev.1' or `lynx-2.8.4.dev1',

Lynx-dev has been using the following scheme for quite some time (years)
consistently:
(read the '^' caret characters as rotated 'less then' signs)

      ........
          ^
    2.8.2dev.1
          ^
    2.8.2dev.N
          ^
      ........
          ^
    2.8.2pre.1
          ^
      ........
          ^
    2.8.2pre.N
          ^
    2.8.2rel.1  a.k.a.  2.8.2
          ^
  ( 2.8.2rel.2 )                [*]
    ( ........ )
          ^
    2.8.3dev.1
          ^
      ........
          ^
    2.8.3dev.N
          ^
    2.8.3pre.1
          ^
      ........
          ^
    2.8.3pre.N
          ^
    2.8.3rel.1  a.k.a.  2.8.3
          ^
  ( 2.8.2rel.2 )                [*]
    ( ........ )
          ^
    2.8.4dev.1
          ^
      ........
          ^
    2.8.4dev.N
          ^
    2.8.4pre.1
          ^
      ......

[*] I don't think that there actually was a rel.2 released for any
version.

Note that these already happen to sort nicely, as long as the full
tokens are used (not the short version to the right of "a.k.a."),
because in ASCII  'd' < 'p' < 'r'.

> both schemes are not
> being ready to be processed by the robot.

Possible solutions:
1.) Only make the TP aware of "releases", use only the (curently)
    three left digits (the short version to the right of "a.k.a.").
2.) "We" (lynx-dev) change our numbering.
3.) The robot is modified, if necessary, to grok our scheme.
4.) Somebody has to translate from our scheme to one acceptable
    by the robot.  Basically what Jim Spath has in mind with
    "re-packaging".

Alternative 1.), the current state?, isn't good.  Translations will lag
a lot behind the code most of the time.  (And people actually use, and
e.g. Linux distributions have been packaging, "dev" versions.  They should
have a better chance of seeing new translation work.)

I see not much chance for 2.) happening, or not soon.  I am not aware of
other good reasons for it, besides the TP's rebotic requirements.

3.) is preferable in my opinion.  If any changes are necessary to the
TP's procedures, they should not be difficult.

Alternative 4.) adds another layer of confusion and another place where
things may go wrong, or not happen in a timely manner.  

> We would also need the PO file
> in advance for any translator submission.

So "somebody" has to execute the algorithm

   IF
       lynx.pot is substantially different from the previous version
   THEN
       mail lynx.pot to TP <address@hidden>

each time a new lynx package is provided?  (or every other time?
every fifth time?)

It would be best if Tom could do that when he updates the code for
download...

> Please attempt to use common versioning schemes before introducing others,
> or make sure I modify the robot in advance for the schemes you introduce.

Please make the robot understand our versioning scheme.

> The difficulty for me is making the robot able to decide, by comparing
> two version strings, which one should be considered the youngest.

That is the same problem that for example various Linux distributions
(Redhat, Debian) have for comparing versions in their package
managers.  Our ordering is compatible with their logic, to the best of
my knowledge.  It should not be too difficult to make the TP robot
understand comparison in the same way, it probably should be done
anyway, not just for lynx.

   Klaus


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden