Improving the Irrlicht release management

CuteAlien · Post by **CuteAlien** » Mon Sep 17, 2007 11:29 am

Irrlicht is releasing very often and I'm certainly happy about that. But it's each time a rather surprising announcement which only happens after the release is done. And while I'm everytime glad to see the new versions, I'm always a little bit irritated that we couldn't get some pre-announcement a few days earlier.

The last Irrlicht versions had some bugs which where fixed within a few days after release. Like for example the gui-focus-problem or the crashs in burning-renderer in 1.3.1. And I'm certain similar bugs will often happen in some releases, simply because it's impossible for the irrlicht-team itself to see all bugs in advance.

But that's a problem all opensource project do face and there is a known solution to that: Do make releasecandidates and announce those. An rc should have a featurefreeze and only bugfixes will be allowed in it. Give it at least 1-2 weeks for the community to test those.

And before someones mentions it - I know certainly that current versions are in SVN. But the problem is that I don't have the time to test those daily or even once per week. But I _would_ do some testing if I know in advance that it is a releasecandidate because I want to see stable final versions. And I'm rather certain that a few other people would also do so.

I hope this will be considered...

hybrid · Post by **hybrid** » Mon Sep 17, 2007 2:38 pm

We are currently finishing 1.4 alpha and will announce a beta phase. That's already planned (esp. due to the large amount of fundamental changes). That's also why I changed the version in SVN already to 1.4 alpha and published some MeshViewer binaries ahead of the full beta SDK.

CuteAlien · Post by **CuteAlien** » Wed Sep 19, 2007 12:08 am

Great, an open announcement for the beta is all I wanted!
I hope it's not just done for 1.4, but for all further releases. Doing open betas is just such a good idea ;-)

hybrid · Post by **hybrid** » Sun Sep 23, 2007 11:29 pm

Ok, revision 1000 is the official start of the Irrlicht 1.4 beta phase! Go ahead testing this version

anylo · Post by **anylo** » Thu Sep 27, 2007 10:08 am

Code: Select all

svn copy --revision 1000 \
https://irrlicht.svn.sourceforge.net/svnroot/irrlicht/trunk \
https://irrlicht.svn.sourceforge.net/svnroot/irrlicht/tags/1.4alpha

hybrid · Post by **hybrid** » Thu Sep 27, 2007 11:24 am

Since we don't add new features ATM ther is no need to tag revision 1000. We are currently at 1004 and there were some minor bug fixes which should make the beta more usable for some people.
The only thing worth tagging (well, we dont have tags, do we?) so worth branching would have been a move of the release candidate into the 1.4 branch which could have be updated until the final release is done.
But most people here are not really confident with SVN here, so it would only raise hundreds of questions how to get the latest 1.4 SVN version. Moreover it increases the bandwidth demand as you have to check-out a complete new repository. This is a flaw in SVN design and this is why I dislike the tagging mechanism of SVN.

mandrav · Post by **mandrav** » Thu Sep 27, 2007 12:51 pm

hybrid wrote:Moreover it increases the bandwidth demand as you have to check-out a complete new repository. This is a flaw in SVN design and this is why I dislike the tagging mechanism of SVN.

You should *really* read the SVN book. It will make you more productive with subversion.
If you 're in a hurry, just read about the switch command. You will realize that it 'd be better if you didn't blame subversion's design (!) if you just don't know how to use it...

alexionne · Post by **alexionne** » Fri Sep 28, 2007 7:09 am

Ok, I'll summarize it in short: when you tag/branch some revision in SVN, you can easily switch to that version using 'switch' command. That command will download only difference between your local version (aka 'working copy') and the version you are switching to.

So, let's say you have trunk forlder containing current SVN revision, and you want to get 1.4 branch but to minimize network traffic. You should create new folder - v1.4 (or something like that), copy complete trunk folder into it (including .svn subdirectories), and than you call 'switch' command on folder v1.4 saying you want to switch to branch 1.4. This is the fastest way to do it

hybrid · Post by **hybrid** » Fri Sep 28, 2007 7:40 am

You see, there's always something to learn

I think I never used switch without --relocate, but that quite regularly. So I revoke my statement that it's a design flaw, I now say it's an unintuitive and inconvenient way

If the SVN guys had made a proper tag database (let it be based on directories or not) it would have been much simpler. Now they have overloaded filesystem commands and you have give lots of meta-information about your repository (or issue several commands to get known to the actual repository layout).
So last question for now: Why would one want revision 1000 tagged? There's no use for it as long as we don't develop on two different branches, right?

Spintz · Post by **Spintz** » Fri Sep 28, 2007 5:36 pm

It's been years, but.....I FINALLY AGREE WITH HYBRID!!!!!

SVN "tag" management is a configuration nightmare.

And branches as well. Branches should be temporary offshoots of the "main branch" for a development path test. After a while, that branch should either be merged into the "main branch" or deleted/removed.

I wish there were more open source options for repositories. CVS and SVN aren't up to par, IMO.

hybrid · Post by **hybrid** » Fri Sep 28, 2007 6:08 pm

You also have git which is said to have much improved branch management. But I never saw it in action.
And I think we had one more thing we agreed on, but I can't recall it anymore

Spintz · Post by **Spintz** » Fri Sep 28, 2007 9:01 pm

Anyone ever try PerForce?

rogerborg · Post by **rogerborg** » Sat Sep 29, 2007 4:11 pm

Some people swear by darcs. I'll concede that it works.

CuteAlien · Post by **CuteAlien** » Sat Sep 29, 2007 6:53 pm

Perforce does cost a lot of money as far as I know.
I've got "testing out new version control systems" on my todo since weeks - not my favourite job ;-) I've heard about darcs, but from what I did read so far it sounded a little bit unfinished. So I'm mostly interested in mercurial, bazaar and git.

SVN does not seem to work for my needs. I have for example X-versions of Irrlicht on my computer and they have already the svn-information for the sourceforge server added. I don't know a way so far to work additionally with an second server at home with the same sources and svn. I suppose I will simply need a distributed source versioning system for that.

So far I'm just working with x-versions and lots of (fast growing) backups. Rather a nightmare.

Spintz · Post by **Spintz** » Sat Sep 29, 2007 6:59 pm

PerForce has an OpenSource development option. It's also free for up to 2 or 5 user accounts.

I tried it a while ago and didn't like it, just because they renamed everything, can't remember the details, but commit was like put, and update was get. I stopped right there.