The International Simutrans Forum

 

Author Topic: Extended in Repo and versioning  (Read 507 times)

0 Members and 1 Guest are viewing this topic.

Offline Frank

  • Inactive/Retired
  • *
  • Posts: 1431
  • Languages: DE
Extended in Repo and versioning
« on: July 05, 2018, 07:11:52 AM »
It's not very helpful for a repository to change published revisions.

Currently the repo contains the published packages pak128.britain-ex 0.9.3 and pak128.schweden-ex 0.1. These are incompatible with the packages on the servers, but they have the same revision number.

Repositories are based on setting the release versions of programs. Which is not the case with the program itself, because there are no releases anymore.

If you can not agree on a repository-compliant versioning, I refrain from setting Extended to Repo.

In addition, Extended does not know where the texts are currently (SVN or Translator).

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18492
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Extended in Repo and versioning
« Reply #1 on: July 05, 2018, 09:52:13 AM »
Thank you for your feedback. I am not sure that I entirely follow what you write, however. Do you mean that the published version numbers (e.g. 0.9.3) do not increment every time that there is a change in the underlying pakset? The reason for this is that I have not found any way of doing this automatically, and manual updating is so laborious as to make it impractical at every minor change. Are you aware of any realistic way of automating this process fully?

Github repositories will always have a commit number. The code itself uses the commit number as the version number, so has an updated commit number in the code automatically for every commit. I have not found any way of doing this for the pakset. However, if an external system or service wishes to query the repository and extract from it a version number, there is no reason in principle that the Git commit number cannot be used for these purposes.

I am not sure what you mean by "refrain[ing] from setting Extended to Repo", I am afraid. Can you elaborate?

As to the final comment, I am not sure that I follow this - when you write that Extended does not know where the texts are currently, may I ask to what part of the code that you are referring? I am not aware of any part of the code itself that checks for texts in a specific place: rather, the code simply expects to find the texts in the relevant folder.

Offline Frank

  • Inactive/Retired
  • *
  • Posts: 1431
  • Languages: DE
Re: Extended in Repo and versioning
« Reply #2 on: July 05, 2018, 10:10:47 AM »
Thank you for your feedback. I am not sure that I entirely follow what you write, however. Do you mean that the published version numbers (e.g. 0.9.3) do not increment every time that there is a change in the underlying pakset? The reason for this is that I have not found any way of doing this automatically, and manual updating is so laborious as to make it impractical at every minor change. Are you aware of any realistic way of automating this process fully?
...

After the release, only the revision in the package (ground.outside) needs to be increased.

Release 0.9.3
-> SVN change to 0.9.4

....
As to the final comment, I am not sure that I follow this - when you write that Extended does not know where the texts are currently, may I ask to what part of the code that you are referring? I am not aware of any part of the code itself that checks for texts in a specific place: rather, the code simply expects to find the texts in the relevant folder.

Normally, when creating a version, the texts are loaded from the translator. Only at Extended many texts / help files in SVN seem to be changed.

So the question arises, which texts should I add to the rpm / deb package data.

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18492
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Extended in Repo and versioning
« Reply #3 on: July 05, 2018, 10:16:40 AM »
I am not sure that I entirely follow - you refer to "after the release": may I ask to what release you are referring?

You also refer to SVN - as you know, Simutrans-Extended does not use SVN, but rather Github, so I am not sure that I understand the reference to SVN.

Offline Frank

  • Inactive/Retired
  • *
  • Posts: 1431
  • Languages: DE
Re: Extended in Repo and versioning
« Reply #4 on: July 05, 2018, 10:30:21 AM »
You misunderstand, the repository is not updated automatically. But I do this by hand and several times for the different bearings rpm and dep. And it will be that I have to create extra branches for some Linux.

So such an update takes a lot of time. Therefore I am not able to add a new version to the repository for every small change of an SVN.

latest post changed

Offline Frank

  • Inactive/Retired
  • *
  • Posts: 1431
  • Languages: DE
Re: Extended in Repo and versioning
« Reply #5 on: July 05, 2018, 10:41:19 PM »
...
Github repositories will always have a commit number. The code itself uses the commit number as the version number, so has an updated commit number in the code automatically for every commit. I have not found any way of doing this for the pakset. However, if an external system or service wishes to query the repository and extract from it a version number, there is no reason in principle that the Git commit number cannot be used for these purposes.
...

Yes and can you tell me which order the applicable versions have?
Quote
extended-125071c
extended-33b9198
extended-5cc69ee
extended-61f000d
extended-93fabe7
extended-a3d5028
extended-eac7640

Offline DrSuperGood

  • Dev Team
  • Devotee
  • *
  • Posts: 2609
  • Languages: EN
Re: Extended in Repo and versioning
« Reply #6 on: July 06, 2018, 05:59:42 AM »
All extended servers should be running nightly at the moment due to how rapidly bugs and such are being fixed. If one does that then the pakset is always the latest build. Like wise all extended paksets are changing rapidly so are also subject to nightly usage.

Stable version numbering is only a concern when there is a stable release. As far as I am aware extended and its paksets will not have one of those for quite a while to come.

Also, to repeat what James said, all Extended development uses GIT and not SVN. The two systems are completely different.

This has its advantages and disadvantages. GIT is considerably more flexible than SVN when it comes to merging. On the other hand SVN does number every commit sequentially making chronology more clear. Since GIT commit number is not useful to anyone outside of the development team, that is why the executable has a build date imbedded into it.

Offline ceeac

  • *
  • Posts: 29
Re: Extended in Repo and versioning
« Reply #7 on: July 06, 2018, 06:27:43 AM »
Yes and can you tell me which order the applicable versions have?

You could try something like
Code: [Select]
git describe --tagswhich provides a linear revision number since the latest git tag, i.e.
Code: [Select]
echo "extended-125071c
extended-33b9198
extended-5cc69ee
extended-61f000d
extended-93fabe7
extended-a3d5028
extended-eac7640" | cut -b 10- | xargs git describe --tags | sort -nr
will output
Code: [Select]
11.35-4461-g125071cda
11.35-4225-geac7640eb
11.35-4171-g61f000db1
11.35-4123-g5cc69ee7f
11.35-4080-g93fabe739
11.35-4022-g33b919821
11.35-3991-ga3d50282a

Online ACarlotti

  • *
  • Posts: 399
Re: Extended in Repo and versioning
« Reply #8 on: July 06, 2018, 07:06:06 AM »
If I understand Frank correctly, the problem is that our current release system is not particularly compatible with having clearly identified versions that can specified and included in software repositories (i.e. 'repository' as in 'Arch User Repository', rather than 'Git repository'). I think this would be a good thing to have because it would make it easier for some people to access the game. The fact that the game is being continuously improved doesn't mean that people can't use versions that are released more widely but on a less frequent basis. Indeed, although Extended is less stable and mature than Standard, I fail to see a qualitative difference in the state of the code that prevents us also making occasional releases.

To support this, I would probably create two new Git branches - 'release' and 'release-candidate'. When creating a new release, we could have the extended testing servers running a release candidate for a few days to allow us to resolve any major/recently-introduced bug fixes before the release (with other changes being placed into master but not tested for a few days until the release has happened). Having a separate stage of testing a release candidate could perhaps be bypassed if master has not been updated for a few days and there were no major new bugs introduced before this time; this would almost certainly be the case for the pakset, which I believe is updated infrequently, but less likely to hold true for the core game itself. Of course, the version number would be incremented for each release (I think when making the first release candidate).

We know that Extended still has lots of bugs, but it is stable enough that it can be played without encountering any major issues - just don't expect anything near 'perfection' yet. (Occasionally we break the nightly quite badly, but this is probably more reason for there being a more stable release version that people can use if they're not actively developing stuff). Having proper numbered releases again will make Simutrans Extended more widely available to might struggle to access it at the moment, or who might not want to worry about a broken nightly destroying (perhaps not obviously) their maps. (And I disagree with DrSuperGood's statement that "All extended servers should be running nightly at the moment").


Regarding the translations, I think the question still remains of how new translations are incorporated (or not) into Extended. (I haven't looked into this at al yet either for Standard or Extended; perhaps I'll be able to answer this question myself later.)

Offline Frank

  • Inactive/Retired
  • *
  • Posts: 1431
  • Languages: DE
Re: Extended in Repo and versioning
« Reply #9 on: July 06, 2018, 07:36:32 AM »
....
Regarding the translations, I think the question still remains of how new translations are incorporated (or not) into Extended. (I haven't looked into this at al yet either for Standard or Extended; perhaps I'll be able to answer this question myself later.)

For automatic retrieval, there is a shell script for Linux.

The set IDs can be found here. The help texts are automatically added to the program texts.The set IDs can be found here. The help texts are automatically added to the program texts.


@DrSuperGood

It's not about whether GIT or SVN is used.

The point is that a user version A is installed and also version A is installed on the server. But version A is not the same as version A.
I'm not interested in confusing users.

If milk is on it then milk should be in there and no beer.
« Last Edit: July 06, 2018, 08:18:02 AM by Frank »

Offline jamespetts gb

  • Simutrans-Extended project coordinator
  • Moderator
  • *
  • Posts: 18492
  • Cake baker
    • Bridgewater-Brunel
  • Languages: EN
Re: Extended in Repo and versioning
« Reply #10 on: July 07, 2018, 12:02:23 AM »
I am still a little unclear as to the context of the original request. Is this in relation to automatic distribution of packaged Linux distributions? Is this in relation to the Simutranslator system? Or is this in relation to something else?

I appreciate that Git has non-sequential version numbering, but, as already stated, manually numbering each version is too labour intensive to be practical. The idea of returning to release builds is interesting; one of the reasons that this was abandoned was the labour insensitivity of doing this, albeit this was before the automatic nightly builds. It may be that it is sensible to get closer to a balanced state before producing release builds.