Welcome to the Java Programming Forums


The professional, friendly Java community. 21,500 members and growing!


The Java Programming Forums are a community of Java programmers from all around the World. Our members have a wide range of skills and they all have one thing in common: A passion to learn and code Java. We invite beginner Java programmers right through to Java professionals to post here and share your knowledge. Become a part of the community, help others, expand your knowledge of Java and enjoy talking with like minded people. Registration is quick and best of all free. We look forward to meeting you.


>> REGISTER NOW TO START POSTING


Members have full access to the forums. Advertisements are removed for registered users.

Results 1 to 7 of 7

Thread: Development Process

  1. #1
    Member
    Join Date
    Jun 2012
    Posts
    41
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default Development Process

    Sorry for the text wall.

    So I didn't know where to best put this, and I feel like a noob...probably because I am. :/ Anyhow, I'm making a project with a google code page and a Git and all that shenanigans, and I've ran into a rather simple problem that I think is very important. I don't know when to make releases. I have a general idea, but I don't know what makes a good point to make a minor release, and when to finally make my first official major release, Alpha 1.0. An even better question is to when an open source game should become Beta. Should I change the way I'm doing things now, by basically having the game be completely open source and public? I'm using Google Code, so I could make it "closed source" and "private" if I wanted too. Does that help create a more solid line between Alpha and Beta?
    The final thing that has been nagging me is I use a Major-Minor-Revision (for hotfixes, and general bug fixes) system, but I've heard of people using a Major-Minor-Build-Revision system, how does that work, and what are the advantages? Finally, you can check out my super lame Alpha 0.0 and get a feeling for the organization I'm doing so far by checking out my Google Code project: lightofday-spacegame - A rogue-like space game with a twist: It just happens to be an arcade style shooter and free roam game at the same time. - Google Project Hosting


  2. #2
    Super Moderator jps's Avatar
    Join Date
    Jul 2012
    Posts
    2,642
    My Mood
    Daring
    Thanks
    90
    Thanked 263 Times in 232 Posts

    Default Re: Development Process

    Compare other software's version numbers to the types of changes that took place between versions and this should give you a general idea, but really it is left up to the author of the code on what numbering system is used.
    Generally my system starts with 0.0.0 code name alpha. This is the raw framework of the code that sets up an environment for the project, perhaps building window and ui components, data structures, just the raw basics, and updates along the way will increase the version number.

    For example, in my project (which is in alpha) I need to add code to create a gui. So my solution is to create a specific type of window with a size and position that depends on the user's display size and resolution, because the way the user sees the gui is important to me. First I create a basic window and make it show. At this point I have code that does a task, and should be testable. My version number might be 0.0.1 now.

    I decide for this project the window should be a perfect square that is 80% of the height of the display. So I write code to size that window. At this point it should be testable. The tests are run on various machines with various display sizes and everything looks to be working as expected. Happy with the code at this point, I save a snapshot as version 0.0.2

    Now this newly opened window should position itself. Done, tested, and happy with the results, version 0.0.3

    At this point I am completely satisfied with the window, and want to move on to the creation of some menu options. This is a major difference than adding on to code that works with the window specifically. I start the menu works with version 0.1.0. This means the window is working as expected (maybe there is a bug? maybe not...) From this version number forward I keep adding code and going through version numbers like 0.1.1, 0.1.2, 0.1.3 etc. Oops, a bug was found on the window. It is a +1 error on centering the window. My version number was 0.1.3 when the bug was discovered and the fix leads me to 0.1.4. With the centering working properly, I can now continue working on my menu code in 0.1.5.

    Happy with the window and the menu, I am at 0.2.0. from here I work on what ever is next. Perhaps a colorful picture for a background. This is when a big problem was discovered. (ok pretend the problem is bigger than what is used in the sample) The previously designed perfect square window should have been a 4:3 ratio width:height. This will upset most of my version 0.1.x code! We are currently at 0.2.0, and making major changes. now all version 0.2.x belong to making changes to the window, previously 0.1.x set. Reshape the window, 0.2.1 tested and happy. Now we no longer want to center the window, but place the bottom left corner of the gui at the bottom left corner of the display, version 0.2.2. Everything seemingly complete, final tests are done, version 0.2.3

    Somewhere around 0.532.25 the code has really taken shape. As it turns out the project was a hangman game. We have the window, the menu, some big splintered post to murder our stick man on, and the logic to start guessing letters. This is no longer in the birth stage of the project. This thing actually looks and functions like a hangman game. Version beta here we are. This is where my private team of testers play a few hundred thousand games of hangman. We love testing so we created a test class which will brute force test all words in our lexicon, as well as our team of testers who will actually play the game.

    Everything looking good, all discovered bugs fixed, seemingly perfect, we release 1.0.0 to the customer as finished product.
    Find another minor bug? Something spelled wrong, some +1 error? perhaps 1.0.1
    Decide on a major change that doesn't really change the way the game is played, but major code work takes place, you may go through 1.0.2, 1.0.3 ...... and end on 1.12.4 by time you got the stick man on the left side of the post instead of the right.
    Here we have an idea for multi-player hangman. Two people play, and it is a race! For every letter one player gets right, the other player has the next part of their stick man drawn! This will be a major change in the way the game is played, and the final version of this may look like 2.5.1


    Oops, another +1 bug. So many on this project. 2.5.2 it is



    but I don't know what makes a good point to make a minor release,
    Generally bug fixes and small changes. (we get 5 wrong guesses instead of 4 before our stick man is fully drawn)




    when to finally make my first official major release
    When you truly believe the code is perfect as is, and are willing to put your stamp of approval on it



    when an open source game should become Beta
    When the code seems to perform the desired tasks, and is testable by people who don't normally write code.



    Should I change the way I'm doing things now, by basically having the game be completely open source and public? I'm using Google Code, so I could make it "closed source" and "private" if I wanted too. Does that help create a more solid line between Alpha and Beta?
    Ultimately version numbers have nothing to do with the decision to be open or closed source, and the decision on both accounts is left up to you, the 'legal owner' of the code.



    Major-Minor-Build-Revision system, how does that work, and what are the advantages?
    With the "system" I employ, record is kept of the code version every successful test phase including the test code. I keep record of which part(s) of the code are done in which version set (in the previous simple example the basic window 'owned' version set 1.1.x, and the menu owned set 1.2.x)

  3. #3
    Super Moderator helloworld922's Avatar
    Join Date
    Jun 2009
    Posts
    2,896
    Thanks
    23
    Thanked 619 Times in 561 Posts
    Blog Entries
    18

    Default Re: Development Process

    To add to jps's answer, I would strongly recommend using source-control software.

    I save a snapshot as version...
    Source control software helps you with this. Each time you make a change you want to keep the source-control software will automatically increment the revision number. At major milestones you can create "checkpoints" or "tags" which would be identified as version 0.2.0, etc. I usually use these for releases which might actually reach an end-user.

    Don't like a change you made? Source control software lets you "revert" back to any previous revision since the dawn of time (well, there are a few limitations). Depending on the source control software you can even revert back to the revision from an hour ago rather than picking a revision number.

    There are a few key details to remember when using source control software:

    1. Commit often and in discrete chunks. This allows you to decide what changes you liked and which ones you didn't by simply changing revisions.

    2. Source control software allows you to leave notes/messages for each commit. Use them. Leave a useful comment about what you changed. Note that comments like "changed app.java" don't really help. Most source control interfaces have ways to automatically show what files where changed. You should focus your comments on how they were changed or what effects the changes have (i.e. "Added a save button to the gui").

    For software which backwards-compatibility may be an issue, I usually use this scheme (incidentally, it's also used by OpenGL and Python):

    The major revision denotes the level of compatibility. For example version 3.0 is compatible with 3.1 but not necessarily compatible with version 2.9 or 4.0.

    The minor revision denotes release milestones in a particular version. For example version 3.0 could be the initial major release then 3.1 could improve the efficiency/speed and/or fix bugs.

    Any small patches/fixes which are released would be 3.0.1, 3.0.2, etc.

    I sometimes include the revision/build number, though this really isn't necessary since I had already created a tag/checkpoint which marks what revision was released.

    I don't see this being too much of an issue for games.

    Popular source control software (I listed the opensource/free ones, commercial apps today are really only used for specialized applications):

    SVN - The one I'm most familiar with. One of the most common ones used in major businesses today. Been around for a really long time so it's really stable and reliable.
    CVS - I'm not familiar with CVS, but I have heard some stories about it. As far as I can tell unless you have to maintain some legacy code which are already using CVS it's best to use SVN. This is also widely used by businesses mostly because it's also really stable and is even older than SVN.
    Mercurial/Hg - One of the new players. It has a fundamentally different design from SVN and CVS. It doesn't really have a centralized server and supposedly scales much better than SVN or CVS. However, being newer it's also not as stable as SVN or CVS. That being said, it's definitely stable enough to be used for most production-ready code.
    GIT - Also fairly new. Has a similar design to Mercurial/Hg in that it doesn't really have a centralized server. I've never really used it too much though I have heard it's more mature than Mercurial/Hg.

  4. #4
    Member
    Join Date
    Jun 2012
    Posts
    41
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default Re: Development Process

    Yeah, I'm using Git, and It has a bit of a learning curve, especially the first time I used the command line and interactive rebase when I made a huge mistake LOL. Why did they have to make VIM so complicated?! Thanks for all the tips.

    EDIT: So now that the practical is gone, what about the hypotheticals? Let's say a new member of the team comes and looks at the history and organization and is like "This is way too confusing". We talk it out, and he tells me how he would organize the project, and it's history. I agree that it kinda makes more sense, but we have to keep the organization of both history and future developments the same. But let's say this happens THREE YEARS IN. What do we do?
    Last edited by lightOfDay; October 13th, 2012 at 02:07 PM.

  5. #5
    Super Moderator helloworld922's Avatar
    Join Date
    Jun 2009
    Posts
    2,896
    Thanks
    23
    Thanked 619 Times in 561 Posts
    Blog Entries
    18

    Default Re: Development Process

    One thing I've learned along the way is the biggest vise of any engineer (same goes for programmers and the likes) is letting perfection getting in the way of good enough. You'll have to figure out how hard it is to implement the changes suggested. Maybe they're worth the effort, maybe they're not. Is the system you're currently using working well? Perhaps you can wait for other major changes and implement some of the bigger ones then, or start picking up the low hanging fruit right away. It depends on the specific situation.

  6. #6
    Member
    Join Date
    Jun 2012
    Posts
    41
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default Re: Development Process

    Cool. Thanks alot, you guys are super helpful.

  7. #7
    Member
    Join Date
    Jun 2012
    Posts
    41
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default Re: Development Process

    Is it proper to use a sort of "prep commit" for A) preparing the particular release/development process for the particular development process/feature to be merged, and B) shaping the history to be more visually appealing and easier to follow?

Similar Threads

  1. Process XML from MQ
    By r15 in forum File I/O & Other I/O Streams
    Replies: 1
    Last Post: June 21st, 2012, 04:32 PM
  2. Process conversation within an app
    By daniel.j2ee in forum Android Development
    Replies: 0
    Last Post: November 1st, 2011, 07:11 AM
  3. Kill a process
    By subhvi in forum Java Theory & Questions
    Replies: 5
    Last Post: January 14th, 2010, 09:11 PM
  4. process control
    By ttsdinesh in forum Java Native Interface
    Replies: 6
    Last Post: October 27th, 2009, 06:29 PM
  5. Patch Process
    By Drakenmul in forum Java Theory & Questions
    Replies: 3
    Last Post: August 2nd, 2009, 03:09 AM