Release Guidelines and discussions

[Chris H.]

A 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".

[Rob Cashwalker]

2 and 5 are really the same.

3 week schedule is definitely more attainable.

Nightly build can only be released with an error-free compile, so all changes submitted must not cause compile errors in the main trunk. Pick a target time that nightly builds will be performed, so that folks know to push their changes in time.

Post the release message skeleton in the dev forum the day before release. Allow devs to provide commentary to be included and "stop the presses" kind of issues that may require delaying the release. Pick a cut-off time for new submissions for the release, maybe even the Thursday night build shall become the new release, other than the "stop the presses" fixes.

[Chris H.]

2 and 5 are really the same.

3 week schedule is definitely more attainable.

`
Hmm, number 2 should be more focused on having a standardized date of release for the betas. With the Nightly Builds now implemented we might be able to scale back on the beta releases.

Once per month? The first Friday of the month might be a good standardized date for release.

This might be enough for the casual members of the user base. The more dedicated members of the user base will likely download the Nightly Builds.

This would give the devs a larger "window" to merge in their major changes and give more time to make any corrections that are needed.

[Sloth]

I would also vote for quality instead of quantity. Every three to four weeks sounds alright. It doesn't have to be a regular schedule as long as there is a notice about 24h before so we can chime in if necessary (can't wait to post "stop the presses" in bold letters).

EDIT: Maybe the next beta can come out sooner since in the last, quests will break after 10 wins and can't be continued.

[friarsol]

EDIT: Maybe the next beta can come out sooner since in the last, quests will break after 10 wins and can't be continued.

Has anything major been added? Maybe we should just release a 1.1.4b so we don't get a thousand bug reports.

[Max mtg]

To my opinion, two weeks iteration is better than three. Wish mtgrares wrote about new versions in his blog.

Version numbering - it's good you're asking about that. Should define how large new feature has to be to increase minor number (1.2 for instance) or revision number.
A refined change list for each release would be fine too (instead of copying changes.txt to new build announcement)

[Chris H.]

I will try to a "maintenance" "build and release" beta this Friday. I do understand the concerns that other people have expressed. I am sorry that things did not turn out better.

The Nightly Builds are a new part of the project and it will take time for everyone to get used to this new form of release. It takes me more than an hour for me to do a single Nightly Build. The beta releases take even more of my time.

The Nightly Builds are a full release and it includes all of the material that is found in the beta archives. I would like to see our dev team suggest that people should download the Nightly Builds to stay current with our dev efforts.

[friarsol]

Hey Chris,

Can you explain why the releases take so much time? I thought that Maven was automating most of this process?

[Chris H.]

Hey Chris,

Can you explain why the releases take so much time? I thought that Maven was automating most of this process?

`
I first boot my computer using the built in hard drive which has the Mac OS X Lion OS installed. I sync and update my local copy to the head version. I run both of the python scripts. I then refresh my local copy and merge in the new material when needed.

At his point I copy and paste the new log messages and the new cards names into the changes.txt file. I then have to reboot my computer using an exterior hard drive with the older Mac OS X Snow Leopard OS.

Once I'm booted into Snow Leopard I then sync the copy of Eclipse that I have installed in the Snow Leopard hard drive up to the rev containing my merge of the updated changes.txt file. I also try to remember to do a Run from within Eclipse after I make sure that there are no build errors.

I then double click on the shell script (Nightly Build or Bi-weekly Beta) that contains the appropriate build and release command. The Maven script needs about 30 to 40+ minutes to complete.

I then need to do an Eclipse refresh followed by a Maven clean to remove the files from with the target folder.

If the release is a beta then I also need to put together an archive containing any new opponent icons and upload to MediaFire. There is also a beta release message to enter into our web site.

The Maven scripts reduce my workload. And I do appreciate Dave's help in this area. I do tend to take a break while the Maven script is running.

[jendave]

Hey Chris,

Can you explain why the releases take so much time? I thought that Maven was automating most of this process?

`
I first boot my computer using the built in hard drive which has the Mac OS X Lion OS installed. I sync and update my local copy to the head version. I run both of the python scripts. I then refresh my local copy and merge in the new material when needed.

At his point I copy and paste the new log messages and the new cards names into the changes.txt file. I then have to reboot my computer using an exterior hard drive with the older Mac OS X Snow Leopard OS.

Once I'm booted into Snow Leopard I then sync the copy of Eclipse that I have installed in the Snow Leopard hard drive up to the rev containing my merge of the updated changes.txt file. I also try to remember to do a Run from within Eclipse after I make sure that there are no build errors.

I then double click on the shell script (Nightly Build or Bi-weekly Beta) that contains the appropriate build and release command. The Maven script needs about 30 to 40+ minutes to complete.

I then need to do an Eclipse refresh followed by a Maven clean to remove the files from with the target folder.

If the release is a beta then I also need to put together an archive containing any new opponent icons and upload to MediaFire. There is also a beta release message to enter into our web site.

The Maven scripts reduce my workload. And I do appreciate Dave's help in this area. I do tend to take a break while the Maven script is running.

Why is the Lion/Snow Leopard reboot dance necessary? I know that the Windows cross-compiler was an issue before. What is the current reason?

[Chris H.]

Why is the Lion/Snow Leopard reboot dance necessary? I know that the Windows cross-compiler was an issue before. What is the current reason?

`
The code which reports the OS and SVN version for the automated bug reporting system is not Lion compatible.

If the jar is built using Snow Leopard then the reported SVN version will be correct. Lion causes a much older SVN version number to be displayed.

If we get an error while running the jar under Mac OS then the OS version reported will be incorrect (java version instead is reported?). I think that this is true if I build using either of the two OS'.

[jendave]

Why is the Lion/Snow Leopard reboot dance necessary? I know that the Windows cross-compiler was an issue before. What is the current reason?

`
The code which reports the OS and SVN version for the automated bug reporting system is not Lion compatible.

If the jar is built using Snow Leopard then the reported SVN version will be correct. Lion causes a much older SVN version number to be displayed.

Arrgghh. I'll look into this one. Just to be clear, when you build using Lion, does the jar Manifest file contain an old SVN version?

If we get an error while running the jar under Mac OS then the OS version reported will be incorrect (java version instead is reported?). I think that this is true if I build using either of the two OS'.

Not a Maven issue, but I take a look at the code on this as well.

[Chris H.]

Arrgghh. I'll look into this one. Just to be clear, when you build using Lion, does the jar Manifest file contain an old SVN version?

`
I think that that is the problem. It was noticed a few weeks ago originally. You and I discussed it briefly at that time.

Someone noticed that a crash report (the old error exception) was reporting an SVN version number that at that time was out of date. I responded by going back to using Snow Leopard for the build and releases and I think that this took card of the problem.

Not a Maven issue, but I take a look at the code on this as well.

`
Oh, the problem with the OS version may be related to the fact that I was using the New Game -> Stack Report command. I seem to remember you saying that you duplicated this issue on your Mac and that code section may need to be updated.

It is not too big of a deal except that it looks like we have about 100 people using Mac OS and forge.

[jendave]

Yes. I found the thread where we discussed it. My memory must be going . The main problem is that I do not use Lion yet (I'll update to it when my workplace does). I'll take a look in any case.

[Chris H.]

I updated the guidelines and made an effort to include all of the suggestions. Thank you everyone.