[rhelgeby]

What kind of release cycle do you prefer?

Current style:
beta1 > beta2 > 3.0.0 release
Advantages: Predictable release dates, some how. All changes and fixes well tested before release, in combination with other fixes in case of conflicts.
Disadvantages: A bit big time span between releases.

Patch style:
beta1 > patches > beta2 > patches > 3.0.0 release
Advantages: More frequent releases (+- a few days, because we need to have some breaks). Smaller downloads per update because resources are excluded from patches.
Disadvantages: Some fixes may just be quickly tested. The patch releases won't be that "awesome" with lots of new cool stuff. And the next beta release will just be a collection of previous patches.

Post additional suggestions if you have some. What style do you perfer?

[exvel]

Well, I think second one is better.
After releasing a final version you can still use this style, 3.0.x for pathces and 3.x.0 for major stuff. It'll be very close to SM release style.

[rhelgeby]

That's the version style, which is pretty close to release cycle.

Currently we use: X.Y.Z

X: Major release. Big changes and major stuff that breaks compatibility, like from 2.5 to 3.0 beta.
Y: Small release. Additions of new features.
Z: Minior release. Mostly bug fixes and small changes.

One thing I'm not sure about is if we should do bug fixes on previous releases, starting from 3.0, 2.5 is obsolete in my point of view.

[exvel]

One thing I'm not sure about is if we should do bug fixes on previous releases

I think it is something that absolutely isn't needed.

[rhelgeby]

Maybe. This plugin is pretty complex, so applying bug fixes to the previous official version could help a bit. But forcing people to upgrade saves us a lot of time working on different branches.

[NouveauJoueur]

2nd one is way better.

[rhelgeby]

Ok, looks like patch style is popular so we'll go for it soon.

I just need to make a little development enviroment with some scripts so we can automate stuff. Less time spent on maintaining.