Nicolas Weeger wrote: > I think one major issue is how long it takes to make a release. > For instance, I know there are some things to do for Windows server/client > (and I will write that down somewhere!), but I don't know how long it takes.
I know this release is taking a bit more time, but that is also because I'm documenting it. the arch and map stuff is pretty easy - it is basically make a copy to the branch, tar it up, and upload it. Even the server and client is pretty easy _if_ everything works correctly. The directions are basically update the configure.in, run autoconf, do make dist. The issue is when things don't work right - someone adds a file but forgets to update the makefile. Then you go through, fix that, repeat the steps, etc, and hopes it works. Also, for the client & server, I do some extra checking, like can I run the client, log into the server, and have it work? Just a basic 'this isn't completely brain dead' type of thing. that takes some extra time, but after being hit one time with something being delivered that was braindead, it seems like a good idea. The time may also depend on your upload speed. Uploading 40 MB of map files takes a little bit of time on an ADSL connection. But in short summary, I'd say that normally it takes the good part of an evening to do a release (2-4 hours). If releases are done more often, I'd expect this to go down some - likelihood of release process getting broken is less when there have only been 20 changes and not 200, etc. > > IMO, what we should do is: > * automatize to the maximum the release process. This can include writing sh > scripts for Linux, scripts for Windows, and so on. [as a side note, I'm > thinking of doing a small C program for Windows to replace the Perl script > for maps, and make the build process more easy, ie change version numbers and > such. C because Perl isn't needed, apart for arch collecting which i can do > on my linux box) > * time how much time a release takes > * decide after we automate to the maximum :) See other post about automation. Certainly more automation can be done, and that shaves some time off. I suppose the main advantage of automation is it could be something that you do a 'make release 1.11', go to bed, and next morning, log on to find everything worked and the files are uploaded to sourceforge. At least for me, it may be a little while before I trust everything that much. And I'm sure it could be automated more - I think it basically came down to: A) Do a write a script to automate it more, which will take X amount of time to write and make sure it works B) Just do it by hand, where it takes Y more time than fully automated Where Y*NUM_RELEASES > X, but unclear what value NUM_RELEASES are. it's also a matter of time concentration. If Y is 10 minutes, not a big deal - just means I go to bed a few minutes later, and shaving 10 minutes off probably means I go to bed 10 minutes earlier. if X is 90 minutes, that is enough time to actually do something relevant - look into fixing some bugs, writing new features, whatever else. > > I would aim for something like a release every 2 months. It may appear short, > but if release process is automated well we don't take much time to release. > It would enable us to have many tests and such. More frequent releases do also have the advantage that there is likely less breakage. > > Note that we should probably do trunk releases too, so people get to test it. The trunk releases get messy, because from what I recall, what we have right now in trunk may not be compatible with final release of 2.0 (in terms of maps, locations, etc). So it gets sort of tricky to put this out there, but don't rely on it too heavily, because things could change in incompatible ways. But that sort of discourages people from using it. Its sort of a different discussion, but the compatible breaking changes should probably be done as soon as possible, so that the rest of more tweaking, fixing bugs, etc. But time doesn't always work that way. _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire