On Sun, Sep 8, 2013 at 6:41 AM, Aaron McCurry <[email protected]> wrote: > As I am working through some of the issues brought up by phunt about the > release I have a couple of questions. > > First should the generated site be checked into trunk so that it's not a > mammoth commit to add it in at every release? (I'm thinking yes) > - This would mean that before every check in would need to generate the > site (which includes javadocs) before each commit. > - And update the project documentation as needed (which should be > happening now) > > Next question, this is something probably for the mentors. Now that we > need to go back and make changes to the 0.2.0 release. Do I drop the > branch and tags in git and start over and leave the version number the > same? Or do I change the version number as a second try? > > I'm leaning toward dropping the 0.2.0 tag and release branch. Fixing > things on the master branch (nothing has changed there since the release > attempt) and re-branching and tagging. > > What the normal practice here?
It's up to you. Here's what's worked for me, keep in mind that I'm influenced by having used SVN for project source control. (it's only recently git became available). What I would suggest is that you tag each RC with an RC# tag. When the RC is approved for release I would add another release specific tag based on the RC# that was approved/released. e.g. release-0.2.0-incubating-RC1, release-0.2.0-incubating-RC2, release-0.2.0-incubating-RC3, etc... (whatever the format you decide). then when you release a particular RC just add a tag release-0.2.0-incubating based on the final RC# that was approved. I typically leave the RC# tags and never remove them. (although in SVN for ZK we actually rename the final RC# to remove the RC#, which is also fine afai concerned) Sound good? Patrick
