New stable release candidate

[jamespetts]

Perhaps we should test 101 to see whether it's stable? I certainly remember that 99.17.1 contains a bug, now fixed, that prevents saved games from being loaded on occasion when players have rotated the map, so a newer stable version would be most welcome...

[DirrrtyDirk]

Even 88.10.5 wasn't without errors. So if you count that, I doubt we ever had a truly "stable" in recent years (ever?)

And except for the - IIRC then still experimental - rotation, 99.17.1 was running pretty well I think. After all it was the first version in 1.5 years (after 88.10.5) that received this label. OTOH 99.17.1 is already more than 12 months old as well... but I'm afraid we're encountering the same problem as usual again: there's always new stuff added before everything of the old stuff works well enough to be really stable... (understandable since developing new stuff is much more exciting and fun than looking for bugs - and developers are supposed to enjoy their work on ST).

So yes, a really smooth and bug-free stable version would be great - but I don't expect it anytime soon (and I can usually live with minor bugs)

[jamespetts]

I don't think, though, that "stable" means no bugs at all - just a version that is stable and tested enough for it to be suitable for those who want just to play with it, without having to worry too much about losing hours of work, to use.

[freegamer]

Is 101 more stable than 99.17.1?  That's the question to ask.

[isidoro]

What about branching?

You can issue a release candidate and continue development of new features on trunk and correcting bugs in RC until considered stable.  With SVN it's very easy.  Even a bug tracking system would be nice to keep trivial messages about bugs apart from the forum.  But that, as usual, requires dedication.  And time is scarce...

When the following stable arrives, the old is not maintained any more and so on.

[jamespetts]

Ahh, Isidoro has an excellent idea - a feature freeze for the trunk version, and any new features going into a branch (or vice versa) to ensure stability. A more stable game will mean more players, which, in turn, will mean more coders and asset makers...

[prissi]

Branching makes a lot of work with svn. Like when something is changed, it will usually conflict with the rest. I tried this two times for the climate version and the pbs signals and it was nightmare.

[ansgar]

Branching makes a lot of work with svn.

Shameless advertisement: Branching, and more important: merging, is much easier to do in Git than in SVN.  Also a DVCS makes contributing easier for people w/o commit access.  With SVN it is almost the same as if there is no VCS...

I still want to create a Git mirror of the SVN repository via git-svn and make it available for anyone who prefers Git.  But I don't know how happy the admin of the repository will be about Git pulling all ~2200(?) revisions once (just the changes between every revision to be correct).

Ansgar

[VS]

No doubt he will be terrified

I just discovered that there is a TortoiseGit, although in early stages (and TortoiseHg). For a vcs to have a Tortoise on your side is an argument akin to an a-bomb. I guess it might become a viable alternative then...

This is getting more and more off-topic... I always wondered about one thing, though: why is the number of people with write access so small? Lately it is effectively only prissi...



On topic. Version releases are now in complete disarray. Perhaps we should adopt a "release early & often" policy (say, every 5 bugs fixed or so), and select stable release candidates "backwards" after some experience? Some two months ago I had a nightly, sadly I can not remember which, but it was absolutely rock-solid.

[prissi]

I am somehow reluctant to use again another CVS system. Does GIT apply a change to the main branch to all side branches? If not I am not sure if there is any improvement.

And we have several SVN. This is the third one and the one which survived the longest. The first was gone with Hendrik due to real life (tm) issues. The second was overwritte by a developer who was confused by commiting and was importing stuff instead. That left us with the current. I can enable more write access; on the other hand all code going through another person (but mine unfourtunately, although tron did from time to time some very critical code review) does add stability to the thing.

And SVN is widely supported and available also clientwise (aka sf, BeOS), while other are much less supported.

[ansgar]

I am somehow reluctant to use again another CVS system. Does GIT apply a change to the main branch to all side branches? If not I am not sure if there is any improvement.

No, not automatically.  You can merge the mainline in a feature branch or the other way round though (git merge <branch>).

And we have several SVN. This is the third one and the one which survived the longest. The first was gone with Hendrik due to real life (tm) issues. The second was overwritte by a developer who was confused by committing and was importing stuff instead. That left us with the current. I can enable more write access; on the other hand all code going through another person (but mine unfourtunately, although tron did from time to time some very critical code review) does add stability to the thing.

Losing a Git repository is not that easy.  Every checkout (clone) is a full copy of the repository including full history.  Note that this is often still smaller than all those ".svn" directories SVN leaves around (all simutrans revisions since 1900 take 3.1 MB Git repo + 10 MB working directory).

With Git, write access to the official repository is also not so important.  Everybody can commit to their local repository and then exchange patches by mail (including commit log) or ask you to `pull' from their repository.  This way patches can still be reviewed before included in the official source.

And SVN is widely supported and available also clientwise (aka sf, BeOS), while other are much less supported.

I have never used BeOS, but Wikipedia says it has a POSIX compatible interface.  That means Git should probably run there.  I also don't use Windows, so I cannot say how things look there either (Git comes from Linux, so there might still be some problems).

Some sites offering free Git hosting can be found at http://git.or.cz/gitwiki/GitHosting.  I think GitHub is supposed to be quite user-friendly and easy to use.

As suggested before, I can import the SVN repository to Git and everybody interested can play around with it.  The official source can still stay in SVN.  For this, I would like the person administrating the SVN repo to say ok and (optional) a userid -> name/email map (Git does not use the login names, but full name and email to identify users; the email address does not need to be actually valid if you don't want to use your real address).

Ansgar

[prissi]

Well, the problem is, that I cannot give you the dump of the svn, since this contains files which are copyrighted, but normal user do not see (since the directory is write protected). Tron runs the svn and I thing you can export it version for version, with one checkout per minute or so. (The first ones are most heavy, since they are the diffs of the entiere revisions. THose I can mail you too.)