Release Guidelines and discussions
Posted: 26 Sep 2011, 01:04A proposal for Release Guidelines:
1} All releases are considered as a beta build. Forge is a work in progress and it is buggy and unfinished. There will be releases that are more unstable than others.
2} Friday may be the best day of the week to release future betas. This gives members of the dev team the following weekend to submit material that may prove to be disruptive to the code base. In the past we have tried other days of the week including Mondays. It may be best to standardize on a specific day of the week if possible.
3} A bi-weekly release schedule may be a best case scenario. Various circumstances may come up at times that make this difficult to obtain. A new release every three to four weeks might be more realistic. A once per month schedule (first Friday of the month?) with an occasional mid-month release might be worth consideration.
4} The Nightly builds provide the user base with a build that includes recent submissions to the SVN code base. Nightly builds can be viewed as replacement to the beta releases. Nightly builds include all of the files that are found in the beta release. We can not guarantee that a new nightly build will appear on a daily basis as unforeseen circumstances can prevent this from occurring. Several Nightly builds per week may be a more realistic approach over the long term.
5} Major changes/submissions to the code base that may be disruptive should be merged into the SVN on the weekend following a beta release. This will give people a chance to find and to fix any problems which may become apparent after a merge. It may be difficult to predict which merges are disruptive and which ones are safe. It could be viewed as something of a crap shoot.
6} Minor new material and bug fixes can be submitted at all times between beta releases. Granted, what is meant to be a minor submission or a minor bug fix could leave the code base in a problematic state. Stuff happens.
7} Major changes to the code base should be discussed with other members of the dev team on the dev topic in advance to submitting the changes to the SVN.
8} The release dev should try to make sure that the code will compile error free and that the forge jar will launch to the New Game window without an error exception prior to running the Maven build and release script. Additional testing beyond this may be difficult.
9} Devs should make sure that their submissions to the SVN allows the project to compile error free. In the past we have had several broken builds. We should try to work together to get the problems resolved.
10} The release dev should try to post a message one to three days in advance that we are nearing the next beta release. This will give the dev team enough notice to "stop the presses" until someone can address an issue that needs to be resolved before the release.
11} The beta release announcements do not need the cryptic commit logs included in the release message. We can continue to include them in the changes.txt file instead.
12} There is a section near the beginning of the changes.txt file below the total number of cards included where members of our dev team can place brief descriptions of their current projects. A brief sentence or two could provide some interesting info for the user base. This info should be non-technical and "easy to read".
1} All releases are considered as a beta build. Forge is a work in progress and it is buggy and unfinished. There will be releases that are more unstable than others.
2} Friday may be the best day of the week to release future betas. This gives members of the dev team the following weekend to submit material that may prove to be disruptive to the code base. In the past we have tried other days of the week including Mondays. It may be best to standardize on a specific day of the week if possible.
3} A bi-weekly release schedule may be a best case scenario. Various circumstances may come up at times that make this difficult to obtain. A new release every three to four weeks might be more realistic. A once per month schedule (first Friday of the month?) with an occasional mid-month release might be worth consideration.
4} The Nightly builds provide the user base with a build that includes recent submissions to the SVN code base. Nightly builds can be viewed as replacement to the beta releases. Nightly builds include all of the files that are found in the beta release. We can not guarantee that a new nightly build will appear on a daily basis as unforeseen circumstances can prevent this from occurring. Several Nightly builds per week may be a more realistic approach over the long term.
5} Major changes/submissions to the code base that may be disruptive should be merged into the SVN on the weekend following a beta release. This will give people a chance to find and to fix any problems which may become apparent after a merge. It may be difficult to predict which merges are disruptive and which ones are safe. It could be viewed as something of a crap shoot.
6} Minor new material and bug fixes can be submitted at all times between beta releases. Granted, what is meant to be a minor submission or a minor bug fix could leave the code base in a problematic state. Stuff happens.
7} Major changes to the code base should be discussed with other members of the dev team on the dev topic in advance to submitting the changes to the SVN.
8} The release dev should try to make sure that the code will compile error free and that the forge jar will launch to the New Game window without an error exception prior to running the Maven build and release script. Additional testing beyond this may be difficult.
9} Devs should make sure that their submissions to the SVN allows the project to compile error free. In the past we have had several broken builds. We should try to work together to get the problems resolved.
10} The release dev should try to post a message one to three days in advance that we are nearing the next beta release. This will give the dev team enough notice to "stop the presses" until someone can address an issue that needs to be resolved before the release.
11} The beta release announcements do not need the cryptic commit logs included in the release message. We can continue to include them in the changes.txt file instead.
12} There is a section near the beginning of the changes.txt file below the total number of cards included where members of our dev team can place brief descriptions of their current projects. A brief sentence or two could provide some interesting info for the user base. This info should be non-technical and "easy to read".
