Time for a new FIFE release?

[mvBarracuda]

The last official release was 2008.2 in July. Although work on rio de hola hasn't been continued due lack of manpower, there have been around 200 commits in the 8 months since then, fixing and improving a bunch of different engine modules.

Considering that rather large-scale changes are currently in the planning stages (redesign of the audio module and the renderer, utf8 support for pychan), I think it's a good idea to release the current trunk as official FIFE package.

There are a number of pros:
* Increase public awareness. Regular releases show that the project is still under somewhat active development. Especially as the latest meeting showed that there is still interest in improving the engine due the games that are utilizing and therefore depend on it.
* Build up confidence. Third party developers are usually extremely cautious to base their efforts upon an engine that has been "abandoned". A new release is a good way to prove that important bugs are addressed and that even new features got mixed in here and there.
* Stable release before potential major changes. As there are quite some severe changes planned for the next months, it's unlikely that we'll release a new version of FIFE before one of them has been implemented and tested. So if we don't release now, we might have to wait several weeks or even months.

Version numbering:
I would prefer a switch in the version number scheme of FIFE. To underline the shift to rather releasing somewhat stable trunk snapshots instead of polished versions of rio de hola together with the engine, I think a version scheme that includes the release date would be more suited. How do you feel about making 2009.03 (year.month) the next release instead of 2009.0(-r1) (year.nth release in this year)?

Tasks:
I'm more than willing to build the win32 release packages, compile a list of changes based on the trac commit listing and do some small release PR. I can't take care of providing linux source packages so in case we would like to provide a linux package as well, we would need a volunteer who could take care of it. Linux release packaging has been documented here:
http://wiki.fifengine.de/Release_packaging#Linux

What do you think? If there are no objections, I'll go ahead and compile something for win32 at the end of the week.

[christoph]

Hi Barra

As I said on IRC I would help out with GNU/Linux packaging. I'm more with the old-school release numbering and would use something like 0.02 or so but your idea is ok as well.

[LinuxDonald]

Let´s talk about this on the next meeting?

[mvBarracuda]

Which will be in about a month. I would prefer a release rather soon as I still got time at the moment; university starts again in April and I'll be attending a conference from March, 22th until March, 29th. So it's unlikely that I'll have much time for release support after that time.

What speaks for and against a release in the next two weeks?

[phoku]

I don't really think we need to rush a release. It seems we're getting new manpower from the users (UH, zero, PARPG) instead of developers interested in FIFE itself, anyway.

If there's a demand for a new release, say by the UH guys, so that they can pin down compatibility or something like that, I wouldn't mind, either.

But otherwise, I think the manpower could be used otherwise :-)

Anyway, I would like to have a discussion about the versioning scheme as the Year.Month scheme fits a distribution, but is not really suited for a framework like FIFE in my opinion.

-phoku

[mvBarracuda]

Oki, I seem to went a bit too fast forward with my proposal, didn't want to upset anyone. However I still feel that releasing a snapshot as stable release is useful especially for public awareness purposes.

It's not really that much manpower would be bound by such a release: christoph would tackle the linux source packages and I'll do the rest. As I don't plan to invest too much time into release PR, the whole release would prolly occupy one day of my time.

Concerning version scheme: what do you think would be best suited phoku? Shoot.

[phoku]

I'm certainly not upset 

If you guys think it's a good idea, go ahead!

Maybe this discussion is the reason I brought up the versioning again. (You did so too.)

Before major releases of the 0.X variety I would like to have see a day or so where we go over the accumulated tickets and fix, discuss or postpone them ...

For a minor release of the 0.X.Y variety this wouldn't be necessary, while major changes would not be allowed to be merged beforehand.

Before we mostly had bigger milestone releases ... maybe it's time to changes this, as you noted,
and I would prefer a more standard version scheme. But that's something we can discuss next meeting.

-phoku

[CheeseSucker]

It has been quite a while since the last FIFE release and there have been some major improvements since then:
 - New greedy pychan layout engine
 - UTF-8 support
 - Rewritten editor
 - And probably more

In my opinion, each of these would warrant a new release. I would go with phoku's suggestion using x.y.z version names.

[mvBarracuda]

I'm fine with that. I'll be pretty busy for the rest of August, but if you can wait until early September, I can take care of the win32 builds.

[CheeseSucker]

Early September should be fine. If you need help with anything, just ask.

I have some questions on our version scheme:

1. Does all/most developers agree on switching to a different version scheme? Perhaps a vote would be in order?

2. I feel FIFE still lacks in both features and stability in order to warrant a 1.0 release, so I would suggest using a 0.x.y version number for now.

3. What should FIFE 1.0 have?

4. What version should the next release be?

[phoku]

Hi,

I opened a poll about the versioning scheme on the general discussion board
(I hope that's a good place).

Also early september sounds good to me, too.

-phoku