Re: [crossfire] 2.0 release, was Re: Code restructuring
(I fear I'll be overly long again, so fasten your seatbelts :)) Le jeudi 20 juillet 2006 07:29, Mark Wedel a écrit : > > Although I do agree that delaying 2.0 too far away would be a bad thing, > > I also think that releasing a 2.0 that would basically be a "1.9 with > > some fixes" would make little sense. > > At some level, all version numbers are arbitrary and can mean whatever. > Sure - yet there are some commonly admitted "values" behind version numbers. Basically, an increase in the major number means a noticeable, significant break from the previous series; a minor usually indicates a "natural" evolution of a given codebase. > In my thinking, the differences of any major release should be seen from > the previous major release (1.0 -> 2.0, 2.0 -> 3.0), not the previous minor > release. In which case a lot has changed from 1.0. > That's a rather strange way of seeing things. The last iteration of the 1.x codebase is 1.9.1, not 1.0. There is no reason to evaluate a new release with one that was made several years ago, and long outdated by an extended evolution process. To put it in another way, do you think players will compare 2.0 against the last known stable version (currently 1.9) or with the 1.0 that's five years old ? > Maybe that isn't great, but as I think was discussed elsewhere, > I wasn't aware of this. > if there is a separate branch for 2.0 (or 3.0 thinking after that), it > probably won't get used much, and before you can really release it to the > general public, you have to make sure it is in fact used. > Sounds a somewhat flawed way of thinking. If you develop a new version of a software - whatever the software is - you cannot expect it to be widely used before it is released. > So this means > that a lot of those features have to put in to the previous version. > No, I don't think so. You can backport *some* features if the new version takes too long to develop, but why would you want to do the work twice ? I see little interest in this. I have the feeling that you consider that leaving the 1.x server for a possibly long period of time without adding more than bugfixes to it is not acceptable - but I personally don't get why this would be a problem; that's a common development cycle and, unless 2.x takes years to be finished, it is hardly an issue for players. > Maybe going forward, there should be a pre-2.0 (or pre-3.0) branch, and > all significant changes have to be put in that branch, so that current > branch only contains bug fixes. But this still goes back to what do the > numbers really need - if most people are running pre 2.0 (pre-2.0-1.9?), > then there are not lots of changes when that is decided to stop calling it > pre 2.0 and make it as a real release. > I don't get why you would need to play with "pre-x" labels - that only adds useless complexity. Let's not forget that the CVS is essentially a developer's tool. Its content is by definition "unreleased code". So I'd suggest to branch whenever we make a new stable release, whatever its version number. The "main" CVS should contain the latest, work-in-progress stuff. The various branches (1.9, 1.10, 2.0) get only bugfixes and can be used to create package revisions (1.9.1, 1.9.2, etc). I think the confusion comes from that currently, a lot of people are using the CVS directly and don't care about the file releases. I don't think it is the best way to ensure a smooth transition process between version, and pertly explains why some important projects get delayed or lack coordination (because the current general assumption is that "the CVS must always work"). > That is a reasonable model - the official version is bug fix only, and > all new features go into what will become the next major version. > > But as said above, snap shots/pre releases of the next major version > still need to be done at some point, and what do we call those? > No, I don't think they need to. But if the goal of such snapshots is to provide some food to the beta-testers, then that's simple: whenever an important development step is done, create an archive of the CVS content, name it with a -bXX suffix and continue to code afterwards. I don't get where this would be a problem. > Sort of goes back to whatever arbitrary numbering scheme we choose. > Yes, but the scheme would be a logical one, and not one that would be based on a rather vague "I think it is time to change the number" feeling. > Problem is that then we will never make another major release, as the > list of things to do will continue to grow. > No, because you can impose a time limit to submit new ideas that needs to be incorporated to the 2.x line. Say for example that "we end discussion on August 31th", have a debate during the first week of September about the submitted ideas, who will do what and what can be dropped because of being too ambitious/irrealistic/whatever else. Currently, there is no such team pl
Re: [crossfire] 2.0 release, was Re: Code restructuring
Mark Wedel wrote: > One thought is to define major.minor.micro releases like this: > > major release: Changes that break compatiblity (need to start with a clean > server as player files are not compatible, server/client compatibility may be > an > issue, and/or programs removed (x11 client goes away for example). > I feel that changes that break compatibility should not be required in order for there to be a major version change, I believe that a major change from the gameplay point of view, would also go to major releases. Also, variability of automated conversion utilities should not disqualify map/arch/playerfile/etc. format changes from going towards a major release. Essentially, what I think should be put into major releases instead of minor, are things that are either, large projects in addition to things that break things. > minor release: feature enhancements and bug fixes. > micro release: only bug fixes. > These definitions work for me, though as noted above, some non-breaking feature enhancements should go to major instead if they truly are a large change (i.e. major code restructuring for example, or things very major from player perspective, should be saved for major releases) > In terms of CVS, that could work out like: > > head branch: Contains major release - all changes (unless not applicable due > to > other changes) go in the head. > > stable branch: This is where minor/micro releases come from. When a new > major > release is done, a new stable (stable-2-0-0, stable-3-0-0) is done. I really > only see one stable branch per major release - the determination of > micro/minor > is a call of the RE at time of release based on what changes. I think in > this > model, releases done on a fairly regular schedule (quarterly? Every 6 > months) > since the number of changes probably won't be that big. > This makes sense, except for one thing. Unless we set up hard cycles of development, or make micro releases for even fixes of things as small as two non-critical bugs, we will have almost no micro releases ever, because every time time there are enough bugfixes to be worth making a micro release, we most likely would also have a couple feature enhancements which would force it to be a minor release instead of micro. One option if we want micro releases to be meaningful, is on a frequent regular basis, check if there are a couple or more bugs that were fixed in the cvs stable branch, and if there were no feature enhancements in that same timeframe, then make a micro release. > The question is then who is responsible for updating the stable branch. IS > the developer who commits the change responsible? Do we have some people > responsible for maintaining the stable branch and they make the call on what > changes to pull out of the main? And you get that thorny issue - what level > of > enhancements from the main branch get put into the stable branch. While some > may be obviously incompatible, there could be other ones which are pretty > significant changes. > Well, I think that we don't have the manpower to maintain a stable branch separately like some larger projects may be able do, hence I think it should be the responsibility of the developer who commits. One other note you didn't really say anything about, is once a major release is released, the only stable branch that should be maintained should be the one for that major release number. What I mean is, when 3.0.0 is released, we should no longer bother with the 2.x.x branch, and the stable branch for 3.x.x will be made, and then the head branch will represent things for 4.0.0. > Under this model, I don't think you want to go too long between making > major > releases - simply because as more time passes, the code from major and stable > will drift farther and farther apart, making it harder and harder to take any > fixes from the main branch to the stable branch - this then basically amounts > to > having two different programs to maintain (and/or the stable branch stops > getting change as if I fix a bug in the head branch and can't easily see in > the > code where that belongs in the stable branch, I may not be inclined to get > the > stable branch, compile, spend the time to debug, etc to try and fix that > problem). > Agreed. For that reason, I also believe that a major code restructure should be done in a major release, and the major release should happen immediately after the restructure is done in order to minimize headaches. > That may work if there are people running these CVS servers and clients. > But > the danger there is it can be hard to run a CVS server when a commit at any > time > could result in the entire server being reset - I think you almost need to > set > up various snapshots where you can say 'the code will be stable enough for at > least some number of months' so people can feel somewhat comfortable playing > on > the server, etc. > Well,
[crossfire] Server console output
Yesterday, I made some tests with the recent CF server (the CVS one). As I wanted to get maximum verbosity, I checked the help, which contains the following: Flags: (...) -d Turns on some debugging. +d Turns off debugging (useful if server compiled with debugging as default). (...) -log Specifies which file to send output to. Only has meaning if -detach is specified. First, I find rather strange that "+d" turns debugging *off* - that's rather counter-intuitive, given that "+" is traditionally attached to the idea of "adding", not "removing". But that's only a minor quibble. On the other hand, the "log" option says that it only has meaning if -detach is specified, but that's not true - it seems that the -log option works in all cases. Second, why is that the output is by default not stdout ? If I launch crossfire without any option from the command line, I'd expect it to give me some output on the console, but it doesn't appear to be the case. I don't even get the confirmation that the server is up and running. There is no obvious indication that the server output goes anywhere, and where. So my question/issue here is twofold: - Shouldn't either the -log option description be corrected or its behavior be changed (I'm not sure which one is "correct") ? - Shouldn't the server launched from the command line send its output by default on stdout ? If not, what's the recommended way to achieve such a result ? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] [Gridarta-devel] Gridarta as Webstart application
Hi all, Hi tchize, Am Mittwoch, 19. Juli 2006 11:51 schrieb Tchize: > Hi, > > I have quite a good amount of experience with webstart. One of the main > drawback of webstart is that it comes from a web environment, that mean > the running application will be in a sandbox, limiting it's > possibilities. It can't access disk space, it can't store datas in user > directory, it can't open network connection. Unless you explicitly put > it as a trusted application, that mean you then need to sign it with a > certificate, and such certificate cost money. You could use a selfsigned > certificate, but then you remove all security, which is a problem in a > web environment where you can't trust. The experimental versions already are with self-signed certificates and request all-permission. I do not see any difference in trust between the completely unsigned Gridarta downloaded from the web and Gridarta signed with a self-signed certificate. Maybe I'd even invest these 30 EUR or whatsoever for a properly signed certificate. Cu :) -- Christian Hujer Free software developer E-Mail: [EMAIL PROTECTED] WWW: http://www.riedquat.de/ ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Gridarta as Webstart application
Hi, I have quite a good amount of experience with webstart. One of the main drawback of webstart is that it comes from a web environment, that mean the running application will be in a sandbox, limiting it's possibilities. It can't access disk space, it can't store datas in user directory, it can't open network connection. Unless you explicitly put it as a trusted application, that mean you then need to sign it with a certificate, and such certificate cost money. You could use a selfsigned certificate, but then you remove all security, which is a problem in a web environment where you can't trust. Christian Hujer wrote: > Hello dear co-devs, > > > I've just started experimenting a bit with Webstart. You can see my first > steps on http://www.riedquat.de/gridarta/webstart > > To me, Webstart currently looks like the future of Gridarta. > I have the following reasons for this opinion: > * It's easy to use for users. > yes > ** Start the application by a click on a link on a webpage. > yes, main point of 'webstart' > ** On Windows it can create desktop and start menu shortcuts. > standalone installers can too > * It will automatically update the application. > can be a problem if one version appear to be bugged and user wants to keep previous :) > * We can easily split the application into several jar files. > standalone can too > * Each jar file is updated separately. > * If the webpage is set up properly, it will even help users to update their > JRE if it's out of date for Gridarta. > > (Note that gridarta webstart is not intended to replace the original > standalone applications, it's intended as an alternative that should be easy > to use and easy to update for users) > > Possible file list A: > * hosted by Gridarta: > ** For Crossfire: > *** gridarta4crossfire.jnlp > *** gridarta4crossfire.jar > ** For Daimonin: > *** gridarta4daimonin.jnlp > *** gridarta4daimonin.jar > ** For both: > *** library jars (gridarta, japi, bsh-*, jlfgr-1_0) > *** legacy jars (rm'ed asap): crimson, jdom, png, visualtek > *** log4j.jar (Ragnor: now open for discussion again) > * hosted by Crossfire: > ** gridarta4crossfire-data.jar > * hosted by Daimonin: > ** gridarta4daimonin-data.jar > > Possible file list B: > * hosted by Crossfire: > ** gridarta4crossfire-data.jar > ** gridarta4crossfire.jnlp > ** gridarta4crossfire.jar > * hosted by Daimonin: > ** gridarta4daimonin-data.jar > ** gridarta4daimonin.jnlp > ** gridarta4daimonin.jar > * hosted by Gridarta: > ** library jars gridarta.jar, japi.jar, bsh-classgen.jar, bsh-commands.jar, > bsh-core.jar, bsh-util.jar, jlfgr-1_0.jar > ** legacy jars (to be removed soon): crimson.jar, jdom.jar, png.jar, > visualtek.jar > ** log4j.jar (now open for discussion again) > > The jnlp needs to be changed if a jar is added or removed. > Having the jnlp with Gridarta means Gridarta has to update the JNLPs if the > projects decide to change their data jar (e.g. split it into two or three > separate jars). > Having the jnlp with the projects means the Projects have to update the JNLPs > if gridarta decides to add / remove library jars / split itself into more > jars. > I haven't found a way of using a split jnlp yet. (Maybe someone knows?) > add a 'ant jnlp -Djnlp.template=' to generate jnlp a common way for all project while letting distributors customize parts of it (like base url)? :D or of course define a few properties in the build.properties :) > I think having the servers in jar archives and deploying / updating them with > the editor package could also come in handy. JNLP allows specifying different > jars for different operating systems, architecture and even locale. > Though it is indeed possible to encapsulate server in the jnlp, take care that the only file extension allowed by webstart is .jar (that's why native libs must be encapsulated in .jars too) and you will have in gridarta to do manual operations to deploy this test server (same apply for maps ^^) > > Feedback welcome, especially from crossfire and daimonin admins / developers > (that's why I crossposted and cc:-ed) > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Yann Chachkoff wrote: >> if there is a separate branch for 2.0 (or 3.0 thinking after that), it >> probably won't get used much, and before you can really release it to the >> general public, you have to make sure it is in fact used. >> > Sounds a somewhat flawed way of thinking. If you develop a new version of a > software - whatever the software is - you cannot expect it to be widely used > before it is released. The biggest danger is that given there are only a handful of servers, if the first release of 2.0 (or whatever major version) has serious problems, it might be hard convincing people to try 2.1, etc And if the changes break compatibility, that makes it even less likely for servers to switch over. > I have the feeling that you consider that leaving the 1.x server for a > possibly long period of time without adding more than bugfixes to it is not > acceptable - but I personally don't get why this would be a problem; that's a > common development cycle and, unless 2.x takes years to be finished, it is > hardly an issue for players. I suppose it depends on how often we plan to do major releases. If only every couple years, this can lead to other problems: 1) To players/users, the project may appear dead (nothing new in the past 12 months) 2) To developers, less satisfaction making changes if no one (outside perhaps a very limited set of developers) will see it for 12 months This can be solved by doing major releases every 6 months (or a year at max) - but that then limits number of changes that can be done in each for each major release. Which may not be a bad thing, but just a note. But last point is scope of changes - if major changes break compatibility, you probably don't want to do them too often - players (and server admins) probably don't want to have to start from scratch every 6 months. > So I'd suggest to branch whenever we make a new stable release, whatever its > version number. The "main" CVS should contain the latest, work-in-progress > stuff. The various branches (1.9, 1.10, 2.0) get only bugfixes and can be > used to create package revisions (1.9.1, 1.9.2, etc). That more or less matches what I said for the CVS branch. I guess if we're not really concerned about stability of major releases, doing pre-releases isn't necessary. But given that major releases will have much larger scale changes, I'd see that number of severity of bugs to potentially be larger. Likewise, if the code isn't being used very much until it is released, it means that a bug for a big change may not be discovered until a year after that change is made. I know from my own developing perspective, I'd much rather find bugs for code I do relatively shortly after I do the code, because the code will be fresher in my mind than if I have to look back at something I did 6 months ago. I suppose in short what I'm saying is it is really nice to have all code actually exercised/used somewhat shortly after the code is written. > I think the confusion comes from that currently, a lot of people are using > the > CVS directly and don't care about the file releases. I don't think it is the > best way to ensure a smooth transition process between version, and pertly > explains why some important projects get delayed or lack coordination > (because the current general assumption is that "the CVS must always work"). yes - that probably isn't a good approach - I think under a new system, servers will need to keep to the stable branch. At the same time, the number of changes in the stable branch will probably be a lot less, so perhaps not as much an issue for servers to keep up to date on that. > >> Problem is that then we will never make another major release, as the >> list of things to do will continue to grow. >> > No, because you can impose a time limit to submit new ideas that needs to be > incorporated to the 2.x line. Say for example that "we end discussion on > August 31th", have a debate during the first week of September about the > submitted ideas, who will do what and what can be dropped because of being > too ambitious/irrealistic/whatever else. > Currently, there is no such team planning - it is basically "free for all"; > it > has its advantages of course, but also major drawbacks, like the inhability > to planify what the next major release will contain. Fair enough. But that model sounds more like 'everyone say what you plan to do for the next major release by august 31st'. Everyone discussing what to do is also good. People saying what they will do is needed. Yet at the same time, I think some rough date has to be put out on when those changes will be completed by. If changes are not done by the date, they get pushed off to next major version (there is of course some wiggle room here, but it isn't uncommon for other various things to happen in ones life which limits the ability to do the work.
Re: [crossfire] 2.0 release, was Re: Code restructuring
Alex Schultz wrote: > Mark Wedel wrote: >> One thought is to define major.minor.micro releases like this: >> >> major release: Changes that break compatiblity (need to start with a clean >> server as player files are not compatible, server/client compatibility may >> be an >> issue, and/or programs removed (x11 client goes away for example). >> > I feel that changes that break compatibility should not be required in > order for there to be a major version change, I believe that a major > change from the gameplay point of view, would also go to major releases. I didn't mean to imply that is the only justification for a major release. Just if such a change is made, no matter how minor otherwise, that should warrant an increase in the major release numbering. > Also, variability of automated conversion utilities should not > disqualify map/arch/playerfile/etc. format changes from going towards a > major release. But those can't always work and/or creates other problems. In the past there have been changes that change things in various ways that would be hard to automate, and/or would make changes to characters that would be unexpected to players (try to explain to players why their stats are different now than last night, or why their item isn't as powerful) - you'll get a lot of upset players in such cases if a player who used to have no problem killing monster X is now killed by it because of changes made to the character. There is also the issue of fairness (character X created before change is made and is thus more powerful than new character Y can be under revised rules). And there is some cost in time, testing, resources of writing such conversion tools. At some level, you just have to say 'hey, the game has changed, start over'. We just have to be careful that doesn't happen too often. >> stable branch: This is where minor/micro releases come from. When a new >> major >> release is done, a new stable (stable-2-0-0, stable-3-0-0) is done. I >> really >> only see one stable branch per major release - the determination of >> micro/minor >> is a call of the RE at time of release based on what changes. I think in >> this >> model, releases done on a fairly regular schedule (quarterly? Every 6 >> months) >> since the number of changes probably won't be that big. >> > This makes sense, except for one thing. Unless we set up hard cycles of > development, or make micro releases for even fixes of things as small as > two non-critical bugs, we will have almost no micro releases ever, > because every time time there are enough bugfixes to be worth making a > micro release, we most likely would also have a couple feature > enhancements which would force it to be a minor release instead of > micro. One option if we want micro releases to be meaningful, is on a > frequent regular basis, check if there are a couple or more bugs that > were fixed in the cvs stable branch, and if there were no feature > enhancements in that same timeframe, then make a micro release. If there are never any micro releases, that is fine IMO. In fact, I'd generally not expect there to be many micro releases, but I could see see a minor release made, a critical bug found a few days later, and can't really justify a minor release, but you need to get a new version out, so do a micro. >> The question is then who is responsible for updating the stable branch. >> IS >> the developer who commits the change responsible? Do we have some people >> responsible for maintaining the stable branch and they make the call on what >> changes to pull out of the main? And you get that thorny issue - what level >> of >> enhancements from the main branch get put into the stable branch. While >> some >> may be obviously incompatible, there could be other ones which are pretty >> significant changes. >> > Well, I think that we don't have the manpower to maintain a stable > branch separately like some larger projects may be able do, hence I > think it should be the responsibility of the developer who commits. > One other note you didn't really say anything about, is once a major > release is released, the only stable branch that should be maintained > should be the one for that major release number. What I mean is, when > 3.0.0 is released, we should no longer bother with the 2.x.x branch, and > the stable branch for 3.x.x will be made, and then the head branch will > represent things for 4.0.0. Yes - I didn't say that in terms of major/stable, but that is how I expect it. It may be reasonable that right after a major release, the stable branch for the previous gets updated for some limited time - sort of same above - if 3.0.0 is released, and the next day, a major bug is discovered that affects the 2.0.0 stable branch, may want to still update that 2.0.0 stable and make a release simply because it may be unreasonable for everyone to switch over to the next major release in a
