Re: [crossfire] 2.0 release, was Re: Code restructuring
Alex Schultz wrote: >> The question is what goes into the stable branch. By its nature, >> everything >> has to go into the head branch (presuming the change is still applicable). >> But >> the scope of changes for the minor releases in the stable branch probably >> shouldn't be too big. >> > Personally, I think things to go into the stable branch, are of course > things we want in minor releases, and in my opinion, that should be > bugfixes, and features that are not large/extensive. Of course, then the > difficulty is in defining how large or extensive makes it worth putting > in for the next major release, and that I believe needs to be decided in > a case-by-case basis. And trying to define what large of extensive may need some clarification. Some of it may just really boil down to what the developer doing the fix in the head wants to do, unless we put requirements that features within some scope must also be in the stable release. For example, I go off and add some new feature to the head branch, but because I'm lazy, don't put it in the stable branch. Thus that feature is only in the head. someone else could port over that change to the stable release if they really want it. However, as I think about, you probably want these features in the stable branch just so they get more use (and thus may find the bugs that can then be fixed in the head branch). But even that can be error prone - I make some minor enhancement which seems like it would be fine for the stable release, but it actually makes use of some new feature not found in the stable release, so that feature then also has to get ported over, etc. This probably isn't an issue, but when we are talking about doing major things to the head release, may not be as uncommon (looking back at the 1.x releases, think about things like the skill/spell redo and key/value lists - there are many minor changes that have been made since that code was committed that requires it). > Personally I would rather dislike that setup, though I don't believe > that is what he is trying to say. What I think he is trying to say is > more like: > > 2.0 release. > branch for 2.1 is made based on 2.0 > 2.1 is release, branch for 2.2 made based on 2.1 > 2.2 is release, branch for 2.3 made based on 2.2 > > That said, I don't see how that would end up much different from just a > branch for each major release, unless we plan on providing bugfix > releases for older releases, which I personally don't see a need to do. Even if we are providing bug fixes, I think it would still be better to branch the stable release for those micro releases then branch the stable for each minor. The other problem with the above scheme is you start getting crazy version numbers in files, as each time you do a branch, if you commit/change a file, you get a couple more decimals placed. So under that scheme, by the time you get to 2.9, you could have files with versions like '1.9.2.5.2.7.1.12.2.23.1.6.2'. I think it is much better, and much more common practice for branches to be based on the smaller pieces, and the main branch/head to be where most of the changes are being made. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Mark Wedel wrote: > Alex Schultz wrote: > >> Andrew Fuchs wrote: >> >>> Finally, i just want to note that our next release could be 1.10.0 >>> instead of 2.0 if we need more time for cf2.0. >>> >> And that is something I strongly believe should be the case. I >> personally do not believe that we are ready for 2.0 for a while (I'm >> thinking about 6 months or so if not a little more), and I believe in >> the meantime that we should do at least one release such as 1.10.0. >> However I believe the point of another release between 2.0 and now to >> gain more time, is fairly moot unless people can work on 2.0 in cvs >> starting fairly soon, hence, I believe that the best solution would be >> to create create a new cvs branch for working on 1.10.0, and then work >> on 2.0 things in the main branch. In terms of debate between making a >> branch for each major version, or each minor version, I personally don't >> have much preference on, but I feel that a branch of some sort is >> needed. Also, I believe the type of code restructure I mentioned a >> little earlier on the mailing list, should be something to target for >> 2.0, though I personally wait about a month to start work on it to allow >> people to get used to usage of the branches and possibly to apply >> pending patches that have been lying around for a while already. >> > > Yes - a stable-1-x branch is needed. > > One question not directly addressed on all of this are the different cvs > trees. > > server: pretty clear on major/stable branching > > client: probably same thing (should the model be followed with client release > matching server release number? > Personally, I think the major and minor version numbers should match, but the micro should be independent, so long as we are releasing the server and client at the same time still, and personally I think we should continue doing that unless someone has a reason that separate releases would be worthwhile. > arch: Does this model make sense? I suppose in some sense because as changes > are made, that may enable or change behaviour of archetypes. What about new > archetypes that are release independent? > > maps: Basically same question applies are for arch. However, maps could be > more > a problem because patching/fixing maps could become very tedious. Well, one issue is that changes in the server that might break the arch format (i.e. separation of multi-meaning attributes), which could cause problems unless we also create arch branches. The same also goes for maps, despite the difficulties in patching/fixing maps. The alternative though to separate branches, would be providing a conversion utility for maps and arches, as map/arch breakage is often easily convertible, with the server. Then apply that to cvs only when the major release making that breakage, is released. I'm not sure which of the options of branches, and conversion utilities, I prefer, however I believe that one of the two would be needed. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Mark Wedel wrote: > Right - I don't think anyone right now is arguably against having the head > be > bleeding edge and aimed for the next major release and another (or multiple) > stable branches. > Agreed. > The question is what goes into the stable branch. By its nature, > everything > has to go into the head branch (presuming the change is still applicable). > But > the scope of changes for the minor releases in the stable branch probably > shouldn't be too big. > Personally, I think things to go into the stable branch, are of course things we want in minor releases, and in my opinion, that should be bugfixes, and features that are not large/extensive. Of course, then the difficulty is in defining how large or extensive makes it worth putting in for the next major release, and that I believe needs to be decided in a case-by-case basis. > I think also it may be best if all the major features go through design > discussions even if there isn't anyone that is necessarily going to work on > them. > > I know that for me personally, there are times when I am unexpectedly ready > to > do some coding. However, if it is going to take 2 weeks to get input from a > design document I write tonight, then 2 weeks from I may not have the time or > inclination. So there needs to be something that people can just pick up > when > ready. > Many discussions on the mailing list are already ones where there isn't necessarily anyone going to work on them :P > 2.0 release. > branch for 2.1 is made based on 2.0 > 2.1 is released, branch for 2.2 made based on current head code > 2.2 is released, branch for 2.3 made based on current head code > > If that is the model, then that really isn't any different than what we do > right now, which means by the time 3.0 is really released, it won't look that > much different than the last previous minor release, since the code for that > previous minor released was based on code pretty close to the 3.0 release > code. > Personally I would rather dislike that setup, though I don't believe that is what he is trying to say. What I think he is trying to say is more like: 2.0 release. branch for 2.1 is made based on 2.0 2.1 is release, branch for 2.2 made based on 2.1 2.2 is release, branch for 2.3 made based on 2.2 That said, I don't see how that would end up much different from just a branch for each major release, unless we plan on providing bugfix releases for older releases, which I personally don't see a need to do. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Alex Schultz wrote: > Andrew Fuchs wrote: >> Finally, i just want to note that our next release could be 1.10.0 >> instead of 2.0 if we need more time for cf2.0. > And that is something I strongly believe should be the case. I > personally do not believe that we are ready for 2.0 for a while (I'm > thinking about 6 months or so if not a little more), and I believe in > the meantime that we should do at least one release such as 1.10.0. > However I believe the point of another release between 2.0 and now to > gain more time, is fairly moot unless people can work on 2.0 in cvs > starting fairly soon, hence, I believe that the best solution would be > to create create a new cvs branch for working on 1.10.0, and then work > on 2.0 things in the main branch. In terms of debate between making a > branch for each major version, or each minor version, I personally don't > have much preference on, but I feel that a branch of some sort is > needed. Also, I believe the type of code restructure I mentioned a > little earlier on the mailing list, should be something to target for > 2.0, though I personally wait about a month to start work on it to allow > people to get used to usage of the branches and possibly to apply > pending patches that have been lying around for a while already. Yes - a stable-1-x branch is needed. One question not directly addressed on all of this are the different cvs trees. server: pretty clear on major/stable branching client: probably same thing (should the model be followed with client release matching server release number? arch: Does this model make sense? I suppose in some sense because as changes are made, that may enable or change behaviour of archetypes. What about new archetypes that are release independent? maps: Basically same question applies are for arch. However, maps could be more a problem because patching/fixing maps could become very tedious. ___ 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: > Le vendredi 21 juillet 2006 07:37, Mark Wedel a écrit : > Now, you could say that "there is no way to be sure that the server works > before trying it"; I'd answer to this that (1) we developers are supposed to > do at least some rough beta testing and (2) nothing prevents us to set a > single beta-testing server clearly flagged as such to get player's feedback > and spot what could have been missed during development. I don't think any developers writes code with known bugs (at least I hope not). while some bugs are pretty obvious if good testing was done, some are less obvious (occur on specific map due to specific setting of flags on objects, etc), but can still be very severe. So I think it is fairly likely that with major changes being made, there will be some number of bugs. A beta server fixes this, presuming you can get enough players on the beta to test it. That's a big unknown at this point. >> 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. >> > Not really - there could be several minor releases, each made with a > relatively short lifecycle (in the order of two-three months, maybe) that > could potentially include a lot of new stuff; the point is that during each > major, no huge, breaking change could occur, so the evolution would be rather > smooth for the server maintainers. They'd also benefit from having releases > that would be more solid than they're now - we currently make no bugfixes > outisde of the CVS itself, forcing them to use the potentially unstable CVS > content to get the fixes. Right - I don't think anyone right now is arguably against having the head be bleeding edge and aimed for the next major release and another (or multiple) stable branches. The question is what goes into the stable branch. By its nature, everything has to go into the head branch (presuming the change is still applicable). But the scope of changes for the minor releases in the stable branch probably shouldn't be too big. > Well, that's part of teamworking. Coding is just the last part of the > process - the design phase, which includes the various discussions, seems at > least as important to me, if not more. There have certainly been cases where things were put in without any such discussion, and I would have liked to have seen some. And the question also becomes what level of changes require design documents? Just the major feature? Any feature beyond some scope (which would need to be defined?) The danger can become that code is submitted/committed that should perhaps have a design document but there wasn't one. Suppose a patch is submitted without a design document? Do we just say 'no design document, do commit?' That may be the right thing to say, but also probably isn't going to make developers very happy. I do think design discussions should be done. But in doing so, I think some rules need to be formulated for when a document is or is not needed (and we have to be careful about code submissions - we don't necessarily want to reject them out of hand, but at the same time, we don't want to accept code that doesn't meet standards). I think also it may be best if all the major features go through design discussions even if there isn't anyone that is necessarily going to work on them. I know that for me personally, there are times when I am unexpectedly ready to do some coding. However, if it is going to take 2 weeks to get input from a design document I write tonight, then 2 weeks from I may not have the time or inclination. So there needs to be something that people can just pick up when ready. I usually try to get around this by putting things out for discussion even when I know I don't have time right now to work on them, on the basis that when I do have time, all discussion is done. Problem then is it can be a very long time before I ever get to it, and if enough time passes, original discussion may not be relevant. >> The only reason I can see of doing that is if there are going to be micro >> releases as well as minor releases (2.1.1 released after 2.2.0). >> > There would be. Suppose that we release a 'stable' 2.1.0 version, put into > its > own CVS branch. Now, somebody finds a couple bugs that we correct. We'd then > update the released package, numbering it 2.1.1, so that people understand > this is a fix of 2.1 rather than a version with new features. > Note that CVS-wise, I do not suggest sub-branching 2.1 into 2.1.0, 2.1.1, > etc; > that's unnecessary overkill. But then how do you cover the case like this: 2.1.0 released. someone puts back some signficant change to stable branch. critical bug is discovered, fix is made, but a 2.1.1 release is needed a week after 2.1.0 One can release 2.1.1 from the stable branch (just like I
Re: [crossfire] 2.0 release, was Re: Code restructuring
> I am also doubtful that changing game mechanisms is the top issue for a > stronger community - rather, that's making the game attractive and fun, by > proposing events in and around them. Many MMORPGs feature special events > around their games (contests, one-time special quests, etc). I think that > should be investigated for Crossfire. We did that on Metalforge a few times, a few DMs. Drawbacks: * it takes time to plan * it takes time to actually eg put items, create stuff, and so on * it takes time to run, because people will connect to the game and want to play * it takes many people to handle everything * also note time zone issue, too But i'd be ready (and eager!) to help do some events from time to time. Just my 0.2€ :) Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Andrew Fuchs wrote: > Finally, i just want to note that our next release could be 1.10.0 > instead of 2.0 if we need more time for cf2.0. And that is something I strongly believe should be the case. I personally do not believe that we are ready for 2.0 for a while (I'm thinking about 6 months or so if not a little more), and I believe in the meantime that we should do at least one release such as 1.10.0. However I believe the point of another release between 2.0 and now to gain more time, is fairly moot unless people can work on 2.0 in cvs starting fairly soon, hence, I believe that the best solution would be to create create a new cvs branch for working on 1.10.0, and then work on 2.0 things in the main branch. In terms of debate between making a branch for each major version, or each minor version, I personally don't have much preference on, but I feel that a branch of some sort is needed. Also, I believe the type of code restructure I mentioned a little earlier on the mailing list, should be something to target for 2.0, though I personally wait about a month to start work on it to allow people to get used to usage of the branches and possibly to apply pending patches that have been lying around for a while already. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Mark Wedel wrote: > Well, a major code restructure can't go into a minor release. Under the > proposed model, the only thing that comes from the main branch is major > releases > - when a major release is done, then a new stable branch is set up where the > minor releases come from. > > Going back to the original issue is code drifting apart - if a major > restructure is done in the main branch, it makes fixing any bugs in both the > main and stable branch more difficult. > > It could just be we live with that difficulty. Or if a major restructure > is > done shortly after a major release, still have to wait for the 6 months or > whatever. I don't really want to try to say 'major code restructures happen > near the end of the cycle' - I think if someone has the code ready and it is > on > the list of things to do, it should be committed. > Agreed, I was just nitpicking about what would be the ideal circumstances, and if someone does have code ready right after a major release, it should indeed still be committed. Personally I think this difficulty would be perfectly fine to live with, provided that those who do the restructuring make sure they keep detailed logs of what functionality of the code moved where in the changelog (i.e. along the lines of "Moved weapon behavior from apply_ob() in item.c to type_weapon_apply() in types/weapons.c"), to make it easier to people to deal with. > > However, as per gros's comment, there needs to be sufficient changes > between > the releases to warrant a major release. We probably don't want to do a new > major release if there are not any signficant changes - I suppose this may be > a > matter of opinion, but if we go in this model, I think that sort of needs to > be > the case, as otherwise we get into confusion at what each branch/release > means. > > There can still certainly be major releases which don't break compatiblity > in > any way but still hold other significant changes (new features, or changing > of > existing features/expanding them). Agreed, I was just pointing out that even with major releases, we should think before breaking things, and if there is a reasonable way to get things done, without breaking, or without making the code messy, etc. then it should be considered. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Le vendredi 21 juillet 2006 20:15, Andrew Fuchs a écrit : > What I'm inferring, and my op pinions: > > Summary: > > While 2.0 should be a significant release, the majority opinion is > that it should not take years. This makes it difficult to implement > what everyone wants, etc. > True. > I think 2.0 should be the point at which most issues that we have > known about, but haven't fixed, should be fixed. I'd get furthermore by saying that the last 1.x should be the point where most issues should be solved. And then, we can start making massive changes leading to the 2.0 version. > Additionally, the > game should be made easier to use (more graphical interfaces on the > client side instead of typing in commands constantly), > Yep - some proposals for the ergonomy of the client would be more than welcome. > Gaining developers: > Agree on all this, although gathering more devs is probably not the most important point ATM. > > Strengthening the community: > > On the community side, we need to encourage player interaction, both > in and out of the game. One way to boost in game interaction would be > bolstering the player economy. > I think that, before entering into such details, we should ask ourselves what is fun in the game and what isn't. And more important, as players what they find fun, and what they don't. I am also doubtful that changing game mechanisms is the top issue for a stronger community - rather, that's making the game attractive and fun, by proposing events in and around them. Many MMORPGs feature special events around their games (contests, one-time special quests, etc). I think that should be investigated for Crossfire. > However, that will probably not be done in time for cf2.0. > Indeed. But that's probably a good time to start thinking about that part, and try to produce a list of what should be done. > For the community out of game, make it easier to find resources like the > forums, and the wiki. Additionally, make > it easier to join irc channels, possibly by putting a java applet > somewhere. > Good idea. Probably make the Forum and Wiki more visible on the front page would also help. > Another thing that could be done to aid the community, > both in-game and outside of the game, would be to setup a method to > connect to servers, just for the purpose of chatting with people who > are playing (oldsocketmode uses food iirc). > Agree. > Another topic of communication between players, would be the inter-server > chat discussed a while ago. > Yep, although that's a little more complex issue to solve. Maybe bridges with the IRC could solve the issue. > My opinion on release numbers: > > Once we have more developers and enough are willing to volunteer, it > may be a good idea to appoint some people to maintain the stable > branches. > Maybe. Note that I don't think we should maintain several stable branches concurrently - only the last release made. I doubt we'd really need specific maintainers in such a scheme. > Micro releases: bug fixes, and addition of small features > Minor releases: Features involving significant changes > Major releases: Huge changes in game play, major overhauls, milestones > in development > I mostly agree with this. Just for the record, I think micro releases probably wont require any CVS branching. I'd put "small features" as "minor release" ones, though - else, we're taking the risk of a slide where most changes become considered as "micro release" ones to make them happen faster. > Finally, i just want to note that our next release could be 1.10.0 > instead of 2.0 if we need more time for cf2.0. > Quite probably. I think we should first fix all the remaining problems, release that as 1.10, and then work on that strong code basis to get a 2.0. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Andrew Fuchs wrote: > On the community side, we need to encourage player interaction, both > in and out of the game. One way to boost in game interaction would be > bolstering the player economy. However, that will probably not be > done in time for cf2.0. For the community out of game, make it easier > to find resources like the forums, and the wiki. Some of this could be done by including notes/links to that in the client itself (perhaps in the about tab). I think most servers may report that info in the motd, but a lot of other info is also displayed at login time, so may not be obvious to everyone (one of those things that when you get shown a bunch of info at one time, becomes more common to just ignore it.) There is also nothing preventing server admins from changing the motd so that it doesn't contain that information. > Additionally, make > it easier to join irc channels, possibly by putting a java applet > somewhere. Not 100% sure about that - presumably most everyone playing will have some irc client available - we should probably make it more obvious (again) on pointing out that the irc channel exists. I personally don't think we want to write/maintain our own irc interface. There might be libraries to make it pretty easy, in which case doing it may not be that hard. But in that case, it should be a pretty specific interface (only connect to the crossfire channel, etc - don't get things too complicated by implementing a complete irc client). If a person is serious about using irc, they should be able (or probably already have) a fully featured irc client. > Another thing that could be done to aid the community, > both in-game and outside of the game, would be to setup a method to > connect to servers, just for the purpose of chatting with people who > are playing (oldsocketmode uses food iirc). IMO, oldsocketmode should just go away - part of the code cleanup. But a simple change for this would be if your on a savebed and not regaining sp/grace/hp, you don't use food. I don't think that would hurt balance and people could be logged in and never eat a bite but still take in conversations, etc. If you want to go out and trade items, whatever, then you would use some food. > Another topic of > communication between players, would be the inter-server chat > discussed a while ago. I think that falls into a major project - not as simple as one might thing - this needs to be properly thought out in many ways. > > ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Le vendredi 21 juillet 2006 07:37, Mark Wedel a écrit : > Yann Chachkoff wrote: > 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 > Well, at least for the code side of things, it seems to me that a software that shows "serious problems" should not get released. Now, you could say that "there is no way to be sure that the server works before trying it"; I'd answer to this that (1) we developers are supposed to do at least some rough beta testing and (2) nothing prevents us to set a single beta-testing server clearly flagged as such to get player's feedback and spot what could have been missed during development. I'd also like to underline that other games suffered serious problems at times, but it wasn't hard to convince people to try the next step, provided that they initially found the game promising/fun/interesting enough. If we are not sure of this, then we may have a content problem that needs to be put on the table. > And if the changes break compatibility, that makes it even less likely > for servers to switch over. > As long as an old version will only get bugfixes, servers will switch over anyway, to have access to the new cool and shiny features. But again, the interest of the new stuff should be strong enough and, if we believe it may not, then we have a problem regarding the content of the game and our relationship towards the player side of the community: it would basically mean that we work without understanding what players need/want/await for. > 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) > Sorry if I sound rude by saying this, but that's ridiculous. Since when a project that mostly releases revisions of a given version is considered 'dead' ? To take a simple example, PHP 4.0 was released in 2000, and PHP 5.0 'only' in 2004 - did people consider it a 'dead project' in the meantime ? Again, I am not saying we should provide "nothing new" - but simply not include "major changes". And I think there are plenty of smaller-scale stuff to keep us busy to provide minor releases anyway. > 2) To developers, less satisfaction making changes if no one > (outside perhaps a very limited set of developers) will see it for 12 > months > First, there are changes that can be introduced by each minor release. Second, major changes worth an upgrade of the major version number are likely to take a long time to complete, maybe months, so the "waiting time" is unlikely to be a problem - you cannot be upset that your code isn't used if you haven't even got enough time to finish it. > 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. > Why would we ever need to base major releases on arbitrary dates ? That's a terrible idea, IMHO. Such changes should be based on the features first, and *then* on some kind of deadline to complete the work, not the reverse. > 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. > Sure. I was more thinking about a rather long cycle for majors - one every two years or so, possibly even longer. > 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. > Then simply open a public beta server using the last usable CVS code. There's no need to play with "pre-xxx" labels of any kind for that. > 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. > Yes, indeed. But that would also include some testing made by the developer(s) it(them)selves. Often, changes made in the CVS currently result in an unusable code because of gross errors that could have been avoided if the coder had spent ten more minutes to build, install and test his/her ne
Re: [crossfire] 2.0 release, was Re: Code restructuring
Alex Schultz wrote: > >> But that can then lead to rapid turnover of major releases. Eg, I do major >> code restructure, make 3.0.0 release. Then some other change is made (maybe >> compatibility breakage, maybe some other code restructure) - do you make a >> 4.0.0 >> release 3 months later then? I think there needs to be some minimum/maximum >> gap >> between major releases. >> > This is true, however I can't see major code restructures working well > as part of a minor release. What I see as ideal though, is if the trunk > gets a few major features almost worthy of a major release, then a code > restructure happens, and a release happens afterwards. Of course, timing > may not work out so ideally, but perhaps it might be good for people to > try to time their major code restructures to finish about just before > when a major release is anticipated. Well, a major code restructure can't go into a minor release. Under the proposed model, the only thing that comes from the main branch is major releases - when a major release is done, then a new stable branch is set up where the minor releases come from. Going back to the original issue is code drifting apart - if a major restructure is done in the main branch, it makes fixing any bugs in both the main and stable branch more difficult. It could just be we live with that difficulty. Or if a major restructure is done shortly after a major release, still have to wait for the 6 months or whatever. I don't really want to try to say 'major code restructures happen near the end of the cycle' - I think if someone has the code ready and it is on the list of things to do, it should be committed. > Yes, this is true, however despite that, not all major releases need > break things, and no sense breaking things unless there is a logical > reason to. > (random thought about old clients: There are a good number of people who > still use the plain X client, the gnome client though, I don't think is > in usage though I may be mistaken) However, as per gros's comment, there needs to be sufficient changes between the releases to warrant a major release. We probably don't want to do a new major release if there are not any signficant changes - I suppose this may be a matter of opinion, but if we go in this model, I think that sort of needs to be the case, as otherwise we get into confusion at what each branch/release means. There can still certainly be major releases which don't break compatiblity in any way but still hold other significant changes (new features, or changing of existing features/expanding them). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
What I'm inferring, and my op pinions: Summary: While 2.0 should be a significant release, the majority opinion is that it should not take years. This makes it difficult to implement what everyone wants, etc. I think 2.0 should be the point at which most issues that we have known about, but haven't fixed, should be fixed. Additionally, the game should be made easier to use (more graphical interfaces on the client side instead of typing in commands constantly), and have a significant amount of balance issues fixed IMO. Another thing is that, I think we should do something to encourage developers to join the project. Finally, a stronger community of players could help this game gain popularity, which would result in more developers. Gaining developers: To get new developers, we first have to have them gain interest in the game, this would fall under building a stronger community. Second, I think reorganizing/restructuring the code into a more logical form, as it is been discussed, and revising/creating more documentation will make it easier for anyone interested in contributing to the project to contribute. Strengthening the community: On the community side, we need to encourage player interaction, both in and out of the game. One way to boost in game interaction would be bolstering the player economy. However, that will probably not be done in time for cf2.0. For the community out of game, make it easier to find resources like the forums, and the wiki. Additionally, make it easier to join irc channels, possibly by putting a java applet somewhere. Another thing that could be done to aid the community, both in-game and outside of the game, would be to setup a method to connect to servers, just for the purpose of chatting with people who are playing (oldsocketmode uses food iirc). Another topic of communication between players, would be the inter-server chat discussed a while ago. My opinion on release numbers: Once we have more developers and enough are willing to volunteer, it may be a good idea to appoint some people to maintain the stable branches. Micro releases: bug fixes, and addition of small features Minor releases: Features involving significant changes Major releases: Huge changes in game play, major overhauls, milestones in development Finally, i just want to note that our next release could be 1.10.0 instead of 2.0 if we need more time for cf2.0. -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Mark Wedel wrote: > 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. > Agreed. >> 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. > Yes, agreed. Not all breakage can be dealt with by conversion scripts in a "proper" manner, however my point was that where conversion IS possible in a safe and "proper" manner we should make converters. (Things like, splitting of multi-meanings for attributes, comes to mind, with regards to converting map data). >>> 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. > I thought you would expect it as such but thought I would bring it up. :-) > 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 few days (I'd say this overlap time would be 1 month at > most, > but then this also sort of depends on how often major releases are done - if > major releases are done every 6 months, then updating to major releases > shouldn't be seen as such a big deal). > That makes sense if there is a demand of it, but I'm not sure if there is, or even if there isn't much of a demand, makes sense for more critical bugs shortly after a release anyways. >>> 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
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
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
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,
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
Alex Schultz wrote: > Mark Wedel wrote: >> 1) What is the target date for a 2.0 release? It can't be 'when all the >> cool >> stuff is done', as then it never happens - always something new to add, etc >> - >> some general date has to targeted. I had previously mentioned shooting for >> end >> of this calendar year. >> > Well, I think that targeting a general date may not be the best > solution, and a better one would be having a feature-based target. > Essentially based upon the sort of things you talk about below. We just > need to limit the number of "must have" things to be reasonable and wait > till we have those, and a few "nice to have" things. Have to be careful and limit the feature so that you don't keep adding more things to be done, to the point where nothing ever gets done. Whatever is targeted for 2.0, there will be things that should be done for 3.0, 4.0, etc. The next version can't hope to cover everything that should be done. > Another issue though, is due to the way that crossfire has released in > the past, releases with minor version number increments are a mixture of > bugfixes, minor features, and major features. One question is, what will > make the difference between 1.9 and 2.0 so different from 1.7 and 1.8? > Really, I don't see how anything that has happened or is planned for > 2.0, will really make the change so much bigger than the difference > between 1.7 and 1.8. For an even better example, the difference between > the releases where the skills system changed a bunch, is probably much > more worthy of a major version change, than what is currently planned > for 2.0 IMHO. Personally, the only way I can see things changing enough > in a single release to in my opinion warrant a 2.0, is if we start > keeping a "stable" branch in CVS and have that used for minor releases, > or if something either in code and/or gameplay undergoes a major (in a > loose sense) restructure. 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). minor release: feature enhancements and bug fixes. micro release: only bug fixes. 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. 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. 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). IMO, this CVS/release model actually is pretty good. The problem is how to handle the head/main CVS branch. It would seem that official releases are never made from it until the target for what constitutes the release is made. 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. I think then also some form of filtering or a separate metaserver is needed so players do play on the appropriate server. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/l
Re: [crossfire] 2.0 release, was Re: Code restructuring
Yann Chachkoff wrote: > Le mercredi 19 juillet 2006 06:50, Mark Wedel a écrit : >> To me, the issue for targetting this for a 2.0 release is timing. >> >> We can come up with a huge list of things that should be done before a >> 2.0 list. And we could attempt to do them all, but then 2.0 probably won't >> be released for 5 years or the like. >> > 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. 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. Maybe that isn't great, but as I think was discussed elsewhere, 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. So this means that a lot of those features have to put in to the previous version. 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'd say that there are basically two types of changes to be done: > > (a) Fixes to problems currently encountered in the 1.9.x version of > Crossfire. > Typically, this is the case for "Game balance" or "Fix weather". Those do not > involve creating new systems, but rather work so that the current stuff does > its job as expected; > > (b) Additions to the existing functionality. Two subtypes here: (1)minor > changes, that are relatively easy to code, or that are mostly not necessary > and (2)major changes, that will require some time to complete, or that change > the game experience in a significant way. > > I'd say that everything that is (a) should be done and integrated as a > release > of the 1.x series - there is no reason to change the major version number for > bugfixes. Similarly, (b.2) would have to go into the 2.x side of things - > major changes is what one expects to have when the major version number > itself changes. Finally, for stuff belonging to (b.1), I'd say that it > depends on the priority we put on it: if it is desperately wanted, then > integrate into the 1.x series; if that's just a nice idea but not really > top-priority, then push to 2.x. 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? Sort of goes back to whatever arbitrary numbering scheme we choose. > >> Depending on the timeframe would determine how many can really be done in >> the targeted time. >> > I think that's a bit backward-thinking: the number of tasks should define the > timeframe, not the opposite. Problem is that then we will never make another major release, as the list of things to do will continue to grow. And there is certainly the case of things that get deferred to the next release. That happens all the time in all sorts of software - it would be nice to have feature X, but doing that means that things won't be completed for another 12 months, so will put feature X into the next version. > >> Bugs, both new and current, also need to be similarly prioritized - >> fixing bugs is great to do, but can also be a big time sink. >> > That's true, but I don't think it is realistic to start working on 2.0 when > 1.x isn't even mostly bug-free. But there are many different types/layers of bugs. Many bugs may fall more into the RFE category or nice to have feature type of thing. And there may be many other bugs that fall more into the inconvenience of slightly annoying. Saying it should be 100% bug free is also one of those things that is likely to never happen (as you fix ones, new ones will always get filed). Pretty much all software ships with some number of bugs. > I'm not even sure there is a clear document for each of those tasks > describing > what we are supposed to add/do/design. I mean, everybody understands > what "new character creation method"; but there is nothing documenting what > has been decided about it, what it should/shouldn't contain, etc. That's > basically a "free for all": the first one that assigns itself to the task and > submit it to the CVS will get its concept becoming the de-facto choice. I'd say that the first person that steps in t
Re: [crossfire] 2.0 release, was Re: Code restructuring
Mark Wedel wrote: > 1) What is the target date for a 2.0 release? It can't be 'when all the cool > stuff is done', as then it never happens - always something new to add, etc - > some general date has to targeted. I had previously mentioned shooting for > end > of this calendar year. > Well, I think that targeting a general date may not be the best solution, and a better one would be having a feature-based target. Essentially based upon the sort of things you talk about below. We just need to limit the number of "must have" things to be reasonable and wait till we have those, and a few "nice to have" things. > 2) What are the 'must have', 'nice to have', and 'not really important' > features > to target for that release? The wiki - > http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by > high/medium/low priorities. Does code restructuring fall into high category? > There is a code cleanup which is high, but I had envisioned that to be a bit > more modest than what is being talked about now. > > Depending on the timeframe would determine how many can really be done in the > targeted time. > I think the real question is, how 'big' do we want 2.0 to be? How much justifies a major version number? The answer to that, affects what features we should target to have in 2.0, and that dictates the timeframe. At the same time though, the timeframe does affect the other parts, it isn't just a one way chain, as we have to also make sure the features are reasonable to complete within a "reasonable" timeframe. What it really is, is not a question of how much can be done in a timeframe, or how 'big' we want it. It is a matter of weighing how 'big' we want it, against what timeframe is "reasonable". Balances are always so much harder to weigh than simple one way relationships ;) Another issue though, is due to the way that crossfire has released in the past, releases with minor version number increments are a mixture of bugfixes, minor features, and major features. One question is, what will make the difference between 1.9 and 2.0 so different from 1.7 and 1.8? Really, I don't see how anything that has happened or is planned for 2.0, will really make the change so much bigger than the difference between 1.7 and 1.8. For an even better example, the difference between the releases where the skills system changed a bunch, is probably much more worthy of a major version change, than what is currently planned for 2.0 IMHO. Personally, the only way I can see things changing enough in a single release to in my opinion warrant a 2.0, is if we start keeping a "stable" branch in CVS and have that used for minor releases, or if something either in code and/or gameplay undergoes a major (in a loose sense) restructure. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] 2.0 release, was Re: Code restructuring
Le mercredi 19 juillet 2006 06:50, Mark Wedel a écrit : > To me, the issue for targetting this for a 2.0 release is timing. > > We can come up with a huge list of things that should be done before a > 2.0 list. And we could attempt to do them all, but then 2.0 probably won't > be released for 5 years or the like. > 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. > The discussion for a 2.0 release probably needs to be done. Several > questions need to be asked & answered: > > 1) What is the target date for a 2.0 release? It can't be 'when all the > cool stuff is done', as then it never happens - always something new to > add, etc - some general date has to targeted. I had previously mentioned > shooting for end of this calendar year. > That's a question that can only be answered once goals to reach for 2.0 are cleared. > 2) What are the 'must have', 'nice to have', and 'not really important' > features to target for that release? The wiki - > http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by > high/medium/low priorities. Does code restructuring fall into high > category? There is a code cleanup which is high, but I had envisioned that > to be a bit more modest than what is being talked about now. > I'd say that there are basically two types of changes to be done: (a) Fixes to problems currently encountered in the 1.9.x version of Crossfire. Typically, this is the case for "Game balance" or "Fix weather". Those do not involve creating new systems, but rather work so that the current stuff does its job as expected; (b) Additions to the existing functionality. Two subtypes here: (1)minor changes, that are relatively easy to code, or that are mostly not necessary and (2)major changes, that will require some time to complete, or that change the game experience in a significant way. I'd say that everything that is (a) should be done and integrated as a release of the 1.x series - there is no reason to change the major version number for bugfixes. Similarly, (b.2) would have to go into the 2.x side of things - major changes is what one expects to have when the major version number itself changes. Finally, for stuff belonging to (b.1), I'd say that it depends on the priority we put on it: if it is desperately wanted, then integrate into the 1.x series; if that's just a nice idea but not really top-priority, then push to 2.x. > Depending on the timeframe would determine how many can really be done in > the targeted time. > I think that's a bit backward-thinking: the number of tasks should define the timeframe, not the opposite. > Bugs, both new and current, also need to be similarly prioritized - > fixing bugs is great to do, but can also be a big time sink. > That's true, but I don't think it is realistic to start working on 2.0 when 1.x isn't even mostly bug-free. > 3) Who commits to working on these changes? The wiki above has lots of > things to do, but very people signed up to do them. If there are only a > few people actively working on making code changes, that certainly limits > number of changes that can be done for a release. > > So all that said, if we think end of the year is a reasonable target > date, I think that limits us to trying to take on somewhere between 2-4 > decent sized projects. If we look at the wiki, taking things currently > marked as high, that would be: > > Character creation - new character creation method > Sounds good for inclusion in 2.0 - new feature that's radically different from what we have. > Game balance - fix various balance issues > Looks like a bugfix to me rather than a new feature - so that's 1.x work, IMHO. > improve client ui > Depends on the level of improvements. If that's just fixing/completing the current client, mark that 1.x (that's basically nothing more than minor tweaks); if that involves rethinking the client UI, then mark that 2.0. > code cleanup (but have to be careful this doesn't lead to rewriting huge > sections of code) > If that's only "cleanup" without any fundamental change in the way it works, then that's definitely an 1.x task. > change password command > Agree, although it looks like a rather minor point to me compared to others. > Of which, none of those currently has anyone signed up to do them (I was > personally planning to look at the character creation sometime soon) > I'm not even sure there is a clear document for each of those tasks describing what we are supposed to add/do/design. I mean, everybody understands what "new character creation method"; but there is nothing documenting what has been decided about it, what it should/shouldn't contain, etc. That's basically a "free for all": the first one that assigns itself to the task and submit it to the CVS will get its concept becoming the de-facto choice. I think that b
[crossfire] 2.0 release, was Re: Code restructuring
To me, the issue for targetting this for a 2.0 release is timing. We can come up with a huge list of things that should be done before a 2.0 list. And we could attempt to do them all, but then 2.0 probably won't be released for 5 years or the like. The discussion for a 2.0 release probably needs to be done. Several questions need to be asked & answered: 1) What is the target date for a 2.0 release? It can't be 'when all the cool stuff is done', as then it never happens - always something new to add, etc - some general date has to targeted. I had previously mentioned shooting for end of this calendar year. 2) What are the 'must have', 'nice to have', and 'not really important' features to target for that release? The wiki - http://wiki.metalforge.net/doku.php/dev_todo:cf2.0 - sort of covers that by high/medium/low priorities. Does code restructuring fall into high category? There is a code cleanup which is high, but I had envisioned that to be a bit more modest than what is being talked about now. Depending on the timeframe would determine how many can really be done in the targeted time. Bugs, both new and current, also need to be similarly prioritized - fixing bugs is great to do, but can also be a big time sink. 3) Who commits to working on these changes? The wiki above has lots of things to do, but very people signed up to do them. If there are only a few people actively working on making code changes, that certainly limits number of changes that can be done for a release. So all that said, if we think end of the year is a reasonable target date, I think that limits us to trying to take on somewhere between 2-4 decent sized projects. If we look at the wiki, taking things currently marked as high, that would be: Character creation - new character creation method Game balance - fix various balance issues improve client ui code cleanup (but have to be careful this doesn't lead to rewriting huge sections of code) change password command Of which, none of those currently has anyone signed up to do them (I was personally planning to look at the character creation sometime soon) I'd also say that generally speaking, any of these big changes needs to be completed at least a month before the targeted release date, simply so there is sufficient time to find bugs, make fixes, then run the fixed code to see if it works, etc. The end of the year date for next release was somewhat arbitrarily chosen, but some date is needed. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
