tchize wrote:
Joining thread a bit late, trolling a bit perhaps :)

I personnaly would enjoy a branch policy on crossfire cvs (whatever it is, a bad decision is always better than no decision).
I don't think we need branching at each release (unless we
want to keep a few weeks after release a bugfixing branch while
devels can develop addons in main branch).

I think the rule on this is that branching at release time will only be done if there is some fix that needs to go in for the release but the latest version of that file can not be used.

 For example, at time of release candidate, player.c is 1.20
a few days later, someone commits some changes (new features) that result in player.c be 1.21 A bug is discovered and fixed in 1.22. That fix is desired for release, so a branch from 1.20 is done with that bug fix.

 So in general, I'd expect branches to be uncommon.



But perhaps, we need more of a release and development policy. I may be the only one to think this, but isn't developpement here a bit too democratic (without much obligation, other than discussing big changes in ML). Coders put add-ons they like and which meet some players need. This is great. But maybe, to have a good release policy, devels should make once a year or alike their 'development plan' (what and when add-ons could be done) and submit it. Then a few reviewer amonst us would analyze all given plan and provide a yearly timeline on when we will release and what should be in for each release.

that could be convenient. But as said before, given a volunteer effort, it is always hard to drive those things.

People probably have enough deadlines to keep at work and school, and don't really want one for something they do for 'fun'.

It's also hard to get volunteer people to do something they don't want to do. So while statements like 'code xyz need to be cleaned up', can be hard to convince someone to do that.

That said, certainly deciding release schedule based a expected features makes sense. If nothing but a few bugfixes, might not be a reason to do a release.

the problem is that can then lead into the current case - long time between releases because it is hard to discern when there are enough notable changes to warrant a release.

that said, doing a release tonight, one thing I found is that aspects of the make dist were broken - more frequent releases should probably keep that more up to date (or at least not as many broken pieces)


Currently, If we go on quarterly releases, i have no idea what is forseen to be on following release! And am sure am not the only one. Lots of other open source projects have a clear idea of what is to be done for when. Even if the delays are not to be followed strictly (some project releases years after forseen date :) ) this give a clear view to users and also to developers.

I think it would certainly be nicer to have a clearer idea of what people are working on and when they expect to complete it. If nothing else, it provides some visibility of what everyone is doing - maybe a wiki someplace? Or maybe something like Leaf maintains for the maps?

Only actual projects/features need to be tracked - if your fixing bugs, don't need to document that - if your writing hundreds of lines of new code, that should probably be tracked.


_______________________________________________
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire

Reply via email to