Re: [crossfire] Crossfire Release Cycles/Methodology
Just a note - I've put a copy of this document, with a few minor changes, on the wiki: http://wiki.metalforge.net/doku.php/crossfire_release_cycle ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
I'm not sure about the other systems out there - once can spend a lot of time looking over all the documentation, etc. AS with our last discussion, I'm most inclined to stick with CVS since we know what it does and doesn't have any real major shortcomings (it works right now). I'm in no way CVS/SVN expert (I use both, but I never really played with branches). IMO, if SVN isn't too bad for branches, we should switch. SVN has atomic transactions, that's a great feature, specially with upcoming talk about restructuration and such - makes it much easier to revert commits. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Also, about restructurations of code, svn unlike cvs does not 'forget' the history of a file when it's moved. I use cvs a lot for work and dureing refactoring of our code (which happens from time to time) we already lost versions of some files because they were deleted / restored / deleted and as result, you have an unconsistent attic (2 files with same name at same directory got deleted, you only have access to latest on in Attic) Nicolas Weeger (Laposte) wrote: I'm not sure about the other systems out there - once can spend a lot of time looking over all the documentation, etc. AS with our last discussion, I'm most inclined to stick with CVS since we know what it does and doesn't have any real major shortcomings (it works right now). I'm in no way CVS/SVN expert (I use both, but I never really played with branches). IMO, if SVN isn't too bad for branches, we should switch. SVN has atomic transactions, that's a great feature, specially with upcoming talk about restructuration and such - makes it much easier to revert commits. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
svn does branching and tagging, and according to this faq (http://subversion.tigris.org/faq.html#merge-using-tags) it does it pretty well. basically svn does this to handle branching and merging copy trunk - myBranch copy myBranch - myBranchMerged modify myBranch at will copy the diff between myBranch and myBranchMerged to trunk CVS on his side does this tag the main branch create a branch from given tag (don't forget to give that branch a name that must be different than tag) modify the branch copy all changes made to branch to main As a result, same number of operation, and svn is 'supposed' to be faster than cvs at this because the operations do not depend on repository size but on change size. I think that because the branch name appear in url, it make it easier for user to checkout a given branch or revision from anonymous svn and the fact branches appear on http browsing (which is not the case of svn) is also a pro for svn. Mark Wedel wrote: Some of SVN big advantages appears to be able to work offline (keeps copy of data you checked out around so you can do diffs without needing connection, as well as ungets). Some of the other features may not make as big a difference to us - ability to use different connection methods (that really is up to the hosting agent) and better binary support. But the fact it doesn't do branching as well as CVS is probably a major shortcoming, especially since we are looking at needing to use branches a lot more. I'm not sure about the other systems out there - once can spend a lot of time looking over all the documentation, etc. AS with our last discussion, I'm most inclined to stick with CVS since we know what it does and doesn't have any real major shortcomings (it works right now). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Nicolas Weeger (Laposte) wrote: Hello. I globally agree, a few points: - Client and server releases will be done at same time, with matching version numbers. - Exception is micro releases, where it may be only the client or only the server released. This supposes client will evolve too. Experience shows client has a development cycle way slower than server. So we may have cases where client doesn't really need to be released. True - OTOH, it isn't really harmful to release the client periodically. Actually, given this release model, the changes in the server will be greatly diminished. If we look back what was done since 1.0, all of the big features would be in the 2.0 target and missing from the 1.x releases. - Major release is done when feature set is complete. That I'm not totally sure I agree. It's nice to agree on a feature set for next major release. But sometimes no one feels working on some point for some months, whereas code moves in another area, enough to warrant a major release. So I'd say we decide on a wanted features list, but we can release a major anyway if enough changes were made. Perhaps ammended that the list can be revisited at various times. If we are talking years between major releases, I think that is a requirement - how can anyone really say what things will be like 18 months from now - things may change such that some new feature/changes is critically needed. Likewise, if there are features on the list that no one is willing to do, it may be reasonable to discuss if those features should really be on that list - if the list is determined by the developers, there should probably be some willingness by the developers to work on those things. I guess the main point is that it should be a surprise to anyone when the release is done. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Mark Wedel wrote: As far as going to something else, I think it would have to be vastly better - sourceforge provides a nice free environment - it keeps things very simple - it is associated with a group, not a single person. Something that is not free or associated with one person can become a problem. Suppose there is some cool site that provides a nice source control package for a relatively nominal amount of money, and I'm willing to pay it. That works great unless I'm hit by a meteorite, and which time, that could just disappear without anyone really knowing why (same points apply to services hosted on a persons private computer, etc - it sounds reasonable, but if something happened to that computer (house burns down), first priority for that person probably isn't getting that server set up again). For such reasons I would agree, we shouldn't go for something that is not free, or associated with one person. My point was more saying that perhaps it would be worth also evaluating the possibility of using some other version control system such as bazaar-ng (personally I think that's a pretty good one, however I don't think it would be a great idea for cf, largely because it becomes rather slow with source trees as large as crossfire, but I was just primarily using that as an example). Personally I currently think that either SVN or CVS are the best options for crossfire, but I just wanted to make a point that other options are worth looking at a little too. In terms of hosting, that is an issue for use of other, the metalforge server may or may not work (don't know if Leaf would or not), however that too has a little bit of those associated with one person potential issues, though it is less significant. One thought, is distributed version control systems would make associated with one person issues less significant, thought it wouldn't eliminate those issues. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Lalo Martins wrote: snip svn criticisms Ahh yes, those are the sorts of SVN issues I've heard about, though I'm not experienced with SVN myself. I believe the idea is to try some proper revision control system like bzr (there's free hosting at launchpad.net; you can host your own using only ssh and a webserver), git/cogito (used by the kernel and many freedesktop.org packages; I'm sure there must be free hosting somewhere) or darcs (again, needs only ssh and http to host). One little note, bzr I find to be rather nice, however I find it's a bit annoyingly memory and cpu intensive on source trees as large as cf. git/cogito looks interesting, the tools seem pretty nice from what little I've looked at, though it will be a bit of pain under windows (and we do have a couple windows-using developers) as under windows it requires cygwin. One other thought, darcs looks like an interesting one too, however the fact that it's written in hacksel makes it a bit of a pain to compile if one can't get binaries for one's system. Personally I'm thinking just sticking with CVS is best though, largely due to sticking with sf being easiest. I'm now thinking that SVN wouldn't be too bad, but wouldn't be worth switching from CVS to use unless one has some significant reason. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Some of SVN big advantages appears to be able to work offline (keeps copy of data you checked out around so you can do diffs without needing connection, as well as ungets). Some of the other features may not make as big a difference to us - ability to use different connection methods (that really is up to the hosting agent) and better binary support. But the fact it doesn't do branching as well as CVS is probably a major shortcoming, especially since we are looking at needing to use branches a lot more. I'm not sure about the other systems out there - once can spend a lot of time looking over all the documentation, etc. AS with our last discussion, I'm most inclined to stick with CVS since we know what it does and doesn't have any real major shortcomings (it works right now). ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
[crossfire] Crossfire Release Cycles/Methodology
Per the recent discussion on code reorganization and what goes in what release, this document is an attempt to gather the points raised and make it into a formal document that can be included in the code or put on the wiki. This document does not attempt to justify or explain why different things are done for reasons of brevity - if we actually want every developer to read it, we want to stick to the what the rules are, and not as much how we arrived at those rules. If I missed anything, or there is strong disagreement on any of these points, speak up. . -- - Crossfire versioning is described as major.minor.micro - 2.3.4 means major version 2, minor 3, micro 4 - The main (head) of the CVS branch contains what will be the next major release. - A branch for the minor releases will be made when a major release is done - It is from this stable-major branch that future minor releases are made. - If a micro release is necessary, it will be branched from the stable-major branch, as stable-major-minor. - The RE may choose to make a branch for an upcoming minor release to limit changes, as stable-major-minor. - Minor releases will be made at periodic intervals (2-4 months apart). - Micro releases will only be done if an immediate release is necessary due to a critical bug, and waiting for the next minor release is not an option. - All releases will be symbolically tagged as rel-major-minor-micro - There is no practical upper limit to minor or micro versions - crossfire 1.16.22 is valid. - Client and server releases will be done at same time, with matching version numbers. - Exception is micro releases, where it may be only the client or only the server released. - Public servers expected to run the stable branch, not the head branch. - stable branch will be made for all arch, maps, client, and server components of crossfire. - What goes in each version of Crossfire: - All changes go into the main head branch, what will become the the next major release. - Smaller features/additions will also be done in the stable branch. - Developer discretion on whether to make change to stable branch in addition to head branch - Bug fixes go in both branches. - Developer making bug fix responsible for updating both branches - Following changes can only be made in the head (next major) branch: - Changes that break compatibility - Changes that make signficant changes to the code. - Removal of programs (discontinue support for a client as an example) - Changing name of executables. - Feature set of next major release to be discussed by developers. - List of proposed changes sent to mailing list. - Developers comment, decide priorities on list of features for next major release. - For major features, brief design document needs to be written, describing the feature, why it is important, and in broad terms, how it will be done. - All changes to protocol must have a design doc, no matter how small. - Design doc must be done before changes are commited - no writing design doc after code is written - Major release is done when feature set is complete. - For 2.0, smaller list of features should be the criteria since this change of release strategy is happening later in the 1.x release cycle. -- Open Issues: - Should we switch to SVN? Switching repositories at same time as switching what the head branch means would make the most sense. - Need some way to drive development - need some way to make sure items on TODO list for next release get done, and that developers just don't work on cool features they want that may not match TODO list. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Release Cycles/Methodology
Mark Wedel wrote: Per the recent discussion on code reorganization and what goes in what release, this document is an attempt to gather the points raised and make it into a formal document that can be included in the code or put on the wiki. snipped the large list Those rules seem to make alot of sense to me. I can't think of any disagreement I have with them. -- Open Issues: - Should we switch to SVN? Switching repositories at same time as switching what the head branch means would make the most sense. I agree that when switching what the head branch means makes the most sense, however I'm not sure that to SVN would be a great type of move to me. SVN from what I've seen does address some of CVS's weaknesses, however I have heard that the way it handles branching for example is ugly. Could someone with more experience with SVN comment on branching in SVN? Also, if we are willing/able to move off of sf.net for version control, it might be worth considering other version control options (I personally think that if we don't use either SVN or CVS, we should see if we can set up a read-only CVS or SVN mirror for people to download off of who don't have the other type of version control software.) - Need some way to drive development - need some way to make sure items on TODO list for next release get done, and that developers just don't work on cool features they want that may not match TODO list Well, the best method of dealing with this I've seen, is with how many projects set things like Blocking 2.0 in their bugzilla system. We might be able to use either categories or priority with the sf.net tracker, however that seems hackish to me and wouldn't be the clearest. That said, I think if we are to continue using the sf.net tracker, it would be best to use that for TODO goals, however I think it may be worth considering moving off of sf.net for bug tracking. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
