![]() ![]() students are strongly encouraged to be detailed, creative, and interactive with the BZFlag developers throughout the application process. There is intentionally no specific format to our applications. Formulate a proposal idea, communicate with devs.Join our #bzflag on Freenode IRC channel.If this interests you, please let us know and submit a GSoC application.īZFlag will not be applying to SOC 2010 in order to concentrate on the release of V3. ![]() In all, the program is a pretty darn good deal for many students, great publicity and marketing for both Google and BZFlag, and an excellent opportunity for attracting new long-term BZFlag developers.Īttracting and mentoring new long-term developers is our primary goal. If the student successfully completes what they propose, they are ultimately paid $4500 for their work and the BZFlag community hopefully gains a new long-term developer. Students are expected to be fully integrated with the BZFlag development community throughout the program, actively engaged in their work, and intently working with the other BZFlag developers throughout the design and implementation of their projects. Students that participate with the BZFlag project are required to adhere to specified development requirements, selected students then work on their projects through the summer. Google allocates a certain number of slots to each participating project/organization which in turn determines how many student developers we get to work with. Student proposals are then reviewed, evaluated, and ranked by the project. The student efforts are focused on projects that they themselves propose to projects such as BZFlag, sometimes catering to ideas that the project suggests or ideas entirely of the student's own conception. Under this program, Google funds students to write code for open source projects during the northern hemisphere's summer timeframe. This is a list of them for historical reference.Starting in 2005, Google has run an open source software development program specifically for students called the Google Summer of Code (GSoC). Some of these development releases had there own pages for development planning. Development versions for major releases are generally not compatible with any other release, including different builds of themselves. These versions are where the developers work on the code that goes into each release. Versions earlier then 1.7c-X were closed source.Įvery release is preceded by a development version. There are currently 40 open source versions of BZFlag. On non-developer releases, the number is generally only incremented and reposed if there was something deficient with the version already posted. Lower patch numbers on a developer revision (where the MINOR number is an odd-number) tend to imply less stability whereas higher patch numbers tend to imply greater stability. Labels and comments that a given release is an RC (Release Candidate) version or that it's a beta or an alpha release are merely intended to describe the stability of a given version but are not part of the version itself. The build number is simply increment for each publishing.Ģ.4.0.1 and 2.4.0.2 are both builds of a 2.4.0 release. Releases are always done with even numbers in the first triplet. ![]() A special case is held for development of a new MAJOR version, it is done using the MINOR version of 99. Incompatable releases use an odd MINOR version. This is what we change to differentiate different downloads of the same code.ĭevelopment Versions and Release Versions ĭevelopment of a new version of BZFlag occurs on the odd version of the lowest required version number. It is updated often and represents only minor changes to the code or packaging system. The BUILD number is incremented each time a package is built and posted. The RELEASE number is iterated across the various releases of that given MAJOR.MINOR version and represents feature additions and enhancements that maintain compatability with all versions sharing the same MAJOR.MINOR pair. The MINOR number represents changes to a version that break it's compatibility with with previous releases. In this version numbering scheme, the MAJOR number implies predominant changes to the software system that makes it visually different from the previous version. This numbering scheme is similar to many open source software projects. The version system uses a 4 digit system that contains the following values The information in following regarding BZFlag's version scheme pertains to the system put into place for the v2.3 /2.4 release Version Numbering Systems History īZFlag has undergone several different numbering schemes over the years (decades) that can be roughly categorized as follows: the 1.7 alphabet soup series, the 1.10 through 2.0 series, and the "new" "quad" system currently in place. 1.3 Development Versions and Release Versions. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |