Re: [crossfire] CVS branches
Brendan Lally wrote: On Monday 08 Aug 2005 07:49, Mark Wedel wrote: If other people want to help with releases, that would be great. Having a more frequent (quarterly) release schedule would also be good. Even people taking some portiosn of the release (maps, archs) reduces the effort a bit on my side - those bits aren't really hard, but if I save myself 15 minutes, that is always nice. I'll volunteer if someone will point me to a suitable HOWTO document/checklist of things to do. this is actually a script I have: #!/bin/sh echo "Did you remember to update the version?" gtar --exclude=CVS --exclude=unlinked --exclude=test -hcvf maps.tar maps gzip -cv9 maps.tar > maps.tar.gz & bzip2 -cv9 maps.tar > maps.tar.bz2& gtar --exclude=CVS --exclude=dev -cvf arch.tar arch gzip -cv9 arch.tar > arch.tar.gz & bzip2 -cv9 arch.tar > arch.tar.bz2& cd crossfire-CVS; make dist cd client-CVS; make archive But the slightly more detailed bits - at least for arch and maps: do cvs update -dp to make sure all up to date. cvs tag rel-1-8-0 (or whatever) to tag the files. Then run those tar and zip commands. The server and client are a little more complicated - in those cases, the version number has to be updated in the configure.am/in file, and then autoconf/automake run, then has to verify that everything does build. Then a cvs commit for those new files, followed by the cvs tag, then followed again by the make dist/archive so that the files distributed really match those. That said, the client really needs to be updated to use automake throughout it. When I put in the gtk-v2 client, it was using automake, so kept that, but its this funky automake/non automake hybrid. automake provides the make dist for us, so as long as the file listing in the makefiles is kept updated, that makes life easier. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
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
Re: [crossfire] CVS branches
Nicolas Weeger wrote: What will be the next server version? 1.7.1 or 1.8.0? If no one object, i'll put a tag for the release candidate tomorrow or friday, so people can again break cvs with commits :) Got my system stable again, and upload 1.8.0 right now. So feel free to commit away. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
On Monday 08 Aug 2005 07:49, Mark Wedel wrote: > If other people want to help with releases, that would be great. Having > a more frequent (quarterly) release schedule would also be good. > > Even people taking some portiosn of the release (maps, archs) reduces the > effort a bit on my side - those bits aren't really hard, but if I save > myself 15 minutes, that is always nice. > I'll volunteer if someone will point me to a suitable HOWTO document/checklist of things to do. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
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). Also there is no need for systematic branching imho. Branching would be very usefull to team develop big change while keeping a relatively stable branch available for common developpers. But, if we tagged the release, branching can be done even months after, but originate from the tagging. This way, if we need branching for release bug-fix, the branch can be created when we first need it! 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. Pehaps crossfire lacks a global analytical part (instead of each coder having their own analysis wich, according to my experience, can be a complete opposite of some other coder analysis) 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. Did i say trolling? Le Samedi 30 Juillet 2005 22:40, Nicolas Weeger a écrit : >Hello. > >I was wondering about the opportunity of making branches when we get >close to releases. > >It would let people go on committing to HEAD, while ensuring code can be >stabilized for release. > >Opinions? Flames? Comments? > >Ryo > >___ >crossfire mailing list >crossfire@metalforge.org >http://mailman.metalforge.org/mailman/listinfo/crossfire -- -- Tchize (David Delbecq) [EMAIL PROTECTED] Public PGP KEY FINGERPRINT: F4BC EF69 54CC F2B5 4621 8DAF 1C71 8E6B 5436 C17C Public PGP KEY location: http://wwwkeys.pgp.net/pgpnet/wwwkeys.html pgpqZ7OheYy5b.pgp Description: PGP signature ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
What will be the next server version? 1.7.1 or 1.8.0? If no one object, i'll put a tag for the release candidate tomorrow or friday, so people can again break cvs with commits :) Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
Mark Wedel wrote: Using tags may actually make more sense. Right now, when I make the actual release, I tag the files, so you can do something like 'cvs checkout -r rel-1-7-0'. But as described about, not until a change happens do you need a branch. So what should probably be done is at the 'code freeze' time do a cvs tag can-1-8-0 or something. Thus, if nothing changes, that can be tagged again as rel-1-8-0 ( can = candidate, rel=release). So if changes are made to CVS head, no big deal - the can- tag is still there to get the files to release. If a fix needs to be backported, the can- tag can be used to find the point to make the branch from. I think this would be a great way to do things. I'm currently not familar with using tags in CVS, however I don't think it would be any real trouble to learn. If other people want to help with releases, that would be great. Having a more frequent (quarterly) release schedule would also be good. Even people taking some portiosn of the release (maps, archs) reduces the effort a bit on my side - those bits aren't really hard, but if I save myself 15 minutes, that is always nice. I could certainly help with some part such as maps or archs etc. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
> I could, if necessary, do a branch commit if there are in fact any > files that are different. But then I suppose the question is why not > just do a branch in the first place. > > But as described about, not until a change happens do you need a > branch. So what should probably be done is at the 'code freeze' time do > a cvs tag can-1-8-0 or something. Thus, if nothing changes, that can be > tagged again as rel-1-8-0 ( can = candidate, rel=release). So if > changes are made to CVS head, no big deal - the can- tag is still there > to get the files to release. If a fix needs to be backported, the can- > tag can be used to find the point to make the branch from. Makes much sense, i'd support doing that. > If other people want to help with releases, that would be great. > Having a more frequent (quarterly) release schedule would also be good. > > Even people taking some portiosn of the release (maps, archs) reduces > the effort a bit on my side - those bits aren't really hard, but if I > save myself 15 minutes, that is always nice. *raises his hand to volunteer (assuming Windows handles correctly scripts to make .tar.gz for releases)* Ryo ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
Nicolas Weeger wrote: Hello. The other issue is that generally, I'm not seeing so many commits that having people hold off a week would seem like much an issue. Well of course we can always wait one or two weeks to add features. But sometimes it's things we'd rather have people test fast than wait weeks. Also need to consider the possibility of finding a weird bug weeks after the release - nice to be able to backport to current stable even after having a whole lot of commits. Yes, although that doesn't come up that often. The simpler approach would not do real branches, just for me to keep a checked out copy and use that when making the release, and bring over changes manually that are critical in nature. Problem with that is you can get the case where there is no version is CVS that directly corresponds to the released version. However, I suppose in that case, a branch for any relevant files could be made at that time. That could work, but you'd also need to send the files to specific platforms maintainers (me for Windows) to have synchronised releases, with same code. I could, if necessary, do a branch commit if there are in fact any files that are different. But then I suppose the question is why not just do a branch in the first place. Of course, within CVS, there really isn't a branch until something needs to be commited that is different. We probably want the main (head) stream to continue to be CVS. So by the time you want a branch, it is in a sense too late (someone has already commited somethign to the head). An in that case, you don't really want a branch, unless you make changes - you just want to note that version x.y is what is going in the main release. Using tags may actually make more sense. Right now, when I make the actual release, I tag the files, so you can do something like 'cvs checkout -r rel-1-7-0'. But as described about, not until a change happens do you need a branch. So what should probably be done is at the 'code freeze' time do a cvs tag can-1-8-0 or something. Thus, if nothing changes, that can be tagged again as rel-1-8-0 ( can = candidate, rel=release). So if changes are made to CVS head, no big deal - the can- tag is still there to get the files to release. If a fix needs to be backported, the can- tag can be used to find the point to make the branch from. But what it really comes down to is that it is more work for the person doing the release (me), and I really don't want to make things any more complicated for myself - I'd much rather be dong stuff more worthwhile than syncing up branches. On the other hand having a branch lets more people contribute to fixing bugs on that release, anyone could backport as opposed to your scenario. Also, I don't think there's a rule in stone saying only you can do releases, is there? :) I'm sure we'd find people to help for that. I'm also pretty sure CVS helps a lot for merging changes. If other people want to help with releases, that would be great. Having a more frequent (quarterly) release schedule would also be good. Even people taking some portiosn of the release (maps, archs) reduces the effort a bit on my side - those bits aren't really hard, but if I save myself 15 minutes, that is always nice. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
Hello. > The other issue is that generally, I'm not seeing so many commits that > having people hold off a week would seem like much an issue. Well of course we can always wait one or two weeks to add features. But sometimes it's things we'd rather have people test fast than wait weeks. Also need to consider the possibility of finding a weird bug weeks after the release - nice to be able to backport to current stable even after having a whole lot of commits. > The simpler approach would not do real branches, just for me to keep a > checked out copy and use that when making the release, and bring over > changes manually that are critical in nature. Problem with that is you > can get the case where there is no version is CVS that directly > corresponds to the released version. However, I suppose in that case, a > branch for any relevant files could be made at that time. That could work, but you'd also need to send the files to specific platforms maintainers (me for Windows) to have synchronised releases, with same code. > But what it really comes down to is that it is more work for the person > doing the release (me), and I really don't want to make things any more > complicated for myself - I'd much rather be dong stuff more worthwhile > than syncing up branches. On the other hand having a branch lets more people contribute to fixing bugs on that release, anyone could backport as opposed to your scenario. Also, I don't think there's a rule in stone saying only you can do releases, is there? :) I'm sure we'd find people to help for that. I'm also pretty sure CVS helps a lot for merging changes. Just my two cents of euro :) Ryo ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
I'd be more concerned about this if there were lots of commits going on, or there was a real desire to have a stable branch (eg, significant changes in main branch that may make it real unstable or incompatible, and thus you want to retain an older branch for compatibility reasons. But the fact is it does add more work - someone has to take patches from the head branch and put them in the stable branch and vice versa. The other issue is that generally, I'm not seeing so many commits that having people hold off a week would seem like much an issue. The simpler approach would not do real branches, just for me to keep a checked out copy and use that when making the release, and bring over changes manually that are critical in nature. Problem with that is you can get the case where there is no version is CVS that directly corresponds to the released version. However, I suppose in that case, a branch for any relevant files could be made at that time. But what it really comes down to is that it is more work for the person doing the release (me), and I really don't want to make things any more complicated for myself - I'd much rather be dong stuff more worthwhile than syncing up branches. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
Alex Schultz wrote: > I think it might be good, though it might complicate things a little > bit. I currently don't know anything about dealing with different > branches in cvs, but I'm sure I could learn easily if I need to. I too think it would be good idea. And I don't think it would complicate things too much: any "normal" developer would just commit to the HEAD version. That means: NO difference for him. Just for critical bugfixes it would require a little more work because somebody would have to add that bugfix to the release branch as well. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
sounds like a good idea. On 7/30/05, Nicolas Weeger <[EMAIL PROTECTED]> wrote: > Hello. > > I was wondering about the opportunity of making branches when we get > close to releases. > > It would let people go on committing to HEAD, while ensuring code can be > stabilized for release. > > Opinions? Flames? Comments? > > Ryo > > ___ > crossfire mailing list > crossfire@metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire > -- Improvement is necessary. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] CVS branches
I think it might be good, though it might complicate things a little bit. I currently don't know anything about dealing with different branches in cvs, but I'm sure I could learn easily if I need to. Alex Schultz Nicolas Weeger wrote: Hello. I was wondering about the opportunity of making branches when we get close to releases. It would let people go on committing to HEAD, while ensuring code can be stabilized for release. Opinions? Flames? Comments? Ryo ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
