This page is being redesigned for the 2023 school year and is being constantly updated.

Be sure to REFRESH this page daily so that you are seeing the latest updates.

Follow the directions on this page.  However, if you get stuck and/or something doesn't make sense, contact your teacher immediately.

After submitting your ONE PAGER, the VERSION SCHEDULE (VS) is the FIRST step of your PREP work.  The VS serves several purposes:

1. It helps you plan your project by identifying all the iterative steps you need to complete to build your project.

2. It helps you manage your time by either:

   • helping to keep you on schedule, or

   • knowing when you might need to adjust your plan because you are too far behind (or too far ahead) of schedule.

3. It keeps links to archives of your completed builds for quick access.

In the VERSION column you will list the VERSION NUMBER that you assign for that task.  Your numbering system should match the modified semantic versioning we use for our class projects (see the section below for more information). Be sure to identify your major updates vs. your minor updates vs. your "baby-steps."

The TASK column will help you organize your build.  This column should list a description of each iteration/build of your project.  You should organize the tasks in the order that you plan to complete each of these builds.  This part of the table should be completed first.  Once you've laid out all your builds, and you have them organized in a logical, sequential order, you can begin to complete the rest of the table.

The SCHEDULE TO FINISH column will help you plan out and schedule your time.  Look at each task.  How long will it take you to complete that task?  What day to you expect to complete that task?  Remember, you only have three weeks.  Many students start with a specific plan for their project.  Then, once they plan out how much time it will take to complete each task, they realize that they may need to modify (add or remove tasks) in order to either finish the build in three weeks OR in order to continue iterating their project over the course of three weeks.

The DATE COMPLETED column will only be filled out when you successfully complete a working version of that task/build AND you have linked to the REMIXED version of that project.  Your task is not considered complete until it is bug free, archived, and linked to your VS.  Only then should you fill out the Date Completed section of your VS.

As you are working, you may find that some tasks take longer than your had anticipated and you might complete other tasks sooner than anticipated.  This is normal.  It's hard to predict, in the very beginning of your project, exactly how everything will play out.  Even if you find that you are getting wildly behind schedule, don't adjust your VS.  Just keep an accurate record of when you complete your work.

However, if you find that you are way ahead of schedule, you will need to modify your VS by adding more tasks to complete.  Remember, your goal is to continue to iterate throughout the entire three weeks of the project.  Do NOT, under any circumstances, stop working if you complete all your tasks.  Your job is to keep iterating for all three weeks.  At the end of three weeks, you will submit what you have.

If you are starting a NEW project, your version numbering should start at 0.0.1 and (ideally) the final version of your project should be version 1.0.0 (a fully functional and complete project - ready for people to use and enjoy). However, depending on the scope of the project, you may not be able to build a project from 0.0.0 to 1.0.0 in three weeks.  Therefore, it is possible to submit a project that is still incomplete (has not reached version 1.0.0) and still receive a good grade.  Likewise, it is also possible that you could complete a fully functional project (made it to 1.0.0) and receive a poor grade because the project you planned out for your three-week project could have been finished in one week.  EVERY. PROJECT. IS. DIFFERENT.

Remember, your goal is to continue to iterate for the entire three weeks.  Your grade is based more on the journey (of continual iterative development) rather the end (whatever project you end up with).

Our class versioning system follows the basic principles of Semantic Versioning but is adapted for our class use. We still use three places with each number separated by a dot (i.e., X.Y.Z where each letter represents a number).

It is important to note that this is NOT a decimal system.  Each number (X, Y, or Z) can be any size.  For example, 1.6.2 is just as valid as 2.823553.38 - it all depends on how you identify the tasks in your build.  For our class we are usually trying to build our project up to VERSION 1. Version 1 is usually considered your first major release of your completely finished, working, and stable project.  Therefore, unless you are extending an already working project, all your version numbers will likely be somewhere in the range from 0.0.0 to 1.0.0.

The X place holds the major version number. This is what we usually hear about with games. Is this version 1 of the game or version 3 of the game. It is reserved for major releases. In our class, if we take a game as an example, we would consider version 1.0.0 to be a fully working game with a splash screen, end screen, a scoreboard to keep track of stats, and multiple levels of increasing difficulty.

The Y place holds the major improvement to your program as you iterate though the builds towards version 1.  For example, version 0.4.0 would be two major iterations BEFORE version 0.6.0 but neither of these iterations (versions) would be our final fully functional program (which would be 1.0.0).

The Z place holds all the iterations of your build as you work through your major improvements.  In class, we usually call these the baby-steps of your iterations.  These are the tiny changes you make in between major improvements of your build.  For example, if between version 0.4.0 and 0.5.0 there were SIX baby-steps that I needed to accomplish the make this change, I would expect to see all of the following version numbers (listed in order from oldest (top) to newest (bottom):

• 0.4.0

• 0.4.1

• 0.4.2

• 0.4.3

• 0.4.4

• 0.4.5

• 0.4.6

• 0.5.0

If 0.4.6 is the last baby-step I need to do to finish my next major change, I don't need 0.4.7.  Instead I jump straight to 0.5.0.  Remember, this is NOT a decimal system.  It is not uncommon to have version numbers that look like this: 0.17.32.  It all depends on YOUR task list.

Finally, EVERY TIME you change your versioning (which is every time you complete a specific task) you should have a saved (REMIXED) file of the game at that version. EVERY saved version of your project should be bug free. 

Never REMIX a "broken" project and never leave a task unfinished.  ALWAYS make sure your new task is working BEFORE you move on to the next step.

If you are new to versioning, you should checkout the sample used on the DODGER game starter tutorial before you get started.  Additionally, you should watch the two videos below to give you more background.