Prepare release "process" for next stable release

[mstovenour]

There are a few of sub-tasks here:

1. Clean up the github wiki documentation discussion and release process
2. Update 3.0 documentation in the source code and on sourceforge using the proposed release process to test the new process
3. Modify various user documentation files in master prior to the 3.1 release to clean up some of the items discussed over the past year

[krkeegan]

Michael, I need a little guidance on what specifically needs to be done.

I went through the changelog page a few days ago and updated everything.

I will look at your release process page and make changes/additions as needed.

[mstovenour]

Before we make any more changes to SF, maybe we can 1st agree and document the plan? As you can see below I've documented the entire process and even run though all of it minus the SF zip/tar ball update. I'll finish that last step today. If anyone disagrees with portions of the proposed process or thinks there should be additional items, let's discuss it.

Review and comment on the following documentation:

• Maintaining MisterHouse Documentation
• Release process of a new stable release

Fully document and test the process by doing a dry run for v3.0 in preparation for a live run for v3.1:

• Merge the master branch into the stable branch
• Test until most are reasonably satisfied
• Tag the release in the stable branch
• Update the change log
• Regenerate and push user documentation to SourceForge
• Push a new zip file to SourceForge
• Announce the new release

[hollie]

Hey Michael,

do you want me to undo the changes to SF? I can do so easily. I don’t want to interfere with your plans, I just thought that since I have the change to change SF now, I might as well do something about the ancient default download for MisterHouse…

Kind regards,
Lieven.

Op 23-dec.-2013, om 16:41 heeft Michael Stovenour [email protected] het volgende geschreven:

Before we make any more changes to SF, maybe we can 1st agree and document the plan? As you can see below I've documented the entire process and even run though all of it minus the SF zip/tar ball update. I'll finish that last step today. If anyone disagrees with portions of the proposed process or thinks there should be additional items, let's discuss it.

Review and comment on the following documentation:

• Maintaining MisterHouse Documentation
• Release process of a new stable release
Fully document and test the process by doing a dry run for v3.0 in preparation for a live run for v3.1:

• Merge the master branch into the stable branch
• Test until most are reasonably satisfied
• Tag the release in the stable branch
• Update the change log
• Regenerate and push user documentation to SourceForge
• Push a new zip file to SourceForge
• Announce the new release
—
Reply to this email directly or view it on GitHub.

[hollie]

Michael,

thanks for taking the time to write this out.

Concerning the ‘Maintaining documentation’ I have a small remark: is it IMHO not required to request access to be able to edit the github wiki. You need a github account, that is the only requirement. I have not put a restriction on editing that wiki on purpose. The wikispace wiki is restricted and I think this requirement is a barrier you should not have in place if you want people to contribute (at least as long as spam is not a problem).

I have documented the steps it currently takes to upload a new version file to the sourceforge page.

Kind regards,
Lieven.

Op 23-dec.-2013, om 16:41 heeft Michael Stovenour [email protected] het volgende geschreven:

Before we make any more changes to SF, maybe we can 1st agree and document the plan? As you can see below I've documented the entire process and even run though all of it minus the SF zip/tar ball update. I'll finish that last step today. If anyone disagrees with portions of the proposed process or thinks there should be additional items, let's discuss it.

Review and comment on the following documentation:

• Maintaining MisterHouse Documentation
• Release process of a new stable release
Fully document and test the process by doing a dry run for v3.0 in preparation for a live run for v3.1:

• Merge the master branch into the stable branch
• Test until most are reasonably satisfied
• Tag the release in the stable branch
• Update the change log
• Regenerate and push user documentation to SourceForge
• Push a new zip file to SourceForge
• Announce the new release
—
Reply to this email directly or view it on GitHub.

[krkeegan]

I made a few small changes to Maintaining MisterHouse Documentation. But it otherwise looks good to me.

I also added my 2 cents to the Release process of a new stable release.

[mstovenour]

1st thanks a bunch for the corrections and clarifications to both pages; all great points and fixes.

As for the SF changes; no need to undo them, I can do that when I'm ready to test the scp commands. Did you only create the v3.0 directory and up load the files? If so I'm about to finalize a method of doing that with scp (which can be automated). If you needed to do any other steps (e.g. indicate which release was "current", etc.) then let me know and I'll try to find a command line version of those steps as well.

I'm thinking about how I might automate the README.txt file. I guess it isn't in the GitHub repository so it can't just be scp'ed. I suppose the release automation script can cat the text into a temp file then scp that file to SF. That, or I can add it to the docs/ directory as something that doesn't draw attention like sourceforge_message.txt.

[hollie]

Hey Michael,

no, there are no further steps required. All I did is documented on the github wiki.

Readme.txt: basically the content will always be the same so it can be generated from the script?

Best regards,
Lieven.

Op 23-dec.-2013, om 22:35 heeft Michael Stovenour [email protected] het volgende geschreven:

1st thanks a bunch for the corrections and clarifications to both pages; all great points and fixes.

As for the SF changes; no need to undo them, I can do that when I'm ready to test the scp commands. Did you only create the v3.0 directory and up load the files? If so I'm about to finalize a method of doing that with scp (which can be automated). If you needed to do any other steps (e.g. indicate which release was "current", etc.) then let me know and I'll try to find a command line version of those steps as well.

I'm thinking about how I might automate the README.txt file. I guess it isn't in the GitHub repository so it can't just be scp'ed. I suppose the release automation script can cat the text into a temp file then scp that file to SF. That, or I can add it to the docs/ directory as something that doesn't draw attention like sourceforge_message.txt.

—
Reply to this email directly or view it on GitHub.

[mstovenour]

ok.. I think I have a process outlined now that will work "and" that we might automate in the future with some ssh keys. I think even the github tagging could be automated. Automated the steps would be:

1. Manually merge master to stable
2. Ask for testers
3. Fix issues in master and stable
4. Run "perl release_the_code_it_wants_to_be_free.pl 3.1"

The hardest part of the automation will be all the error checking at each step. Feel free to update the page if you find any issues. It will be fun to try it out for v3.1.

BTW, it might take a while for SF to recognize the new v3.0 file again. When I deleted and recreated the directory the SF "download" button reverted to the old v2.105 version again. I'll keep checking to make sure it wasn't something I broke.

Finally, I modified the content of the README on SF so it doesn't need to be moved/edited for each release. (e.g. can't say "latest release" once new release comes out, changes to markdown format, moved to top level directory so doesn't need to be touched during the release process, etc.). At this point I think we could merge the content of the SF and GitHub README.md files. What do you all think?

[hollie]

Hey Michael,

the SF link looks OK to me, I think it picked the most recent file up again already.

Let’s indeed try your flow once we agree 3.1 is ready for release!

Regarding the README on SF: as long as it links to github, to me it is OK.

Best regards,
Lieven.

Op 24-dec.-2013, om 15:35 heeft Michael Stovenour [email protected] het volgende geschreven:

ok.. I think I have a process outlined now that will work "and" that we might automate in the future with some ssh keys. I think even the github tagging could be automated. Automated the steps would be:

1. Manually merge master to stable
2. Ask for testers
3. Fix issues in master and stable
4. Run "perl release_the_code_it_wants_to_be_free.pl 3.1"

The hardest part of the automation will be all the error checking at each step. Feel free to update the page if you find any issues. It will be fun to try it out for v3.1.

BTW, it might take a while for SF to recognize the new v3.0 file again. When I deleted and recreated the directory the SF "download" button reverted to the old v2.105 version again. I'll keep checking to make sure it wasn't something I broke.

Finally, I modified the content of the README on SF so it doesn't need to be moved/edited for each release. (e.g. can't say "latest release" once new release comes out, changes to markdown format, moved to top level directory so doesn't need to be touched during the release process, etc.). At this point I think we could merge the content of the SF and GitHub README.md files. What do you all think?

—
Reply to this email directly or view it on GitHub.

[hollie]

In the same 'documentation' category: I tried to clarify the documentation on how to contribute code after Rick asked this question on the mailing list.

Is this better than it was before?

https://github.com/hollie/misterhouse/wiki/Contributing#developing-using-git

I tried to write it more from the mindset of somebody who is new to git.

[mstovenour]

I think you've added some clarity to the process for those new to Git. (I was new when you moved MH to GitHub). I just have two general comments:

It seems to now include the content under creating a pull request; maybe this section is no longer needed.

One of the omissions is the process required to keep the fork updated with changes from hollie/misterhouse. In my workflow I've created another remote called upstream. I then fetch upstream, merge hollie/master, push origin. Ideally I do this before creating a new fix or feature branch to cut down on the potential for merge conflicts.

[hollie]

Hey Michael,

I've added some more links and some more details. I think it makes sense to keep both sections: one is the long-and-detailed one for people new to git, the other one is a shorter step-by-step for people who are already somewhat comfortable with git. I've added text to clarify this.

On keeping your working copy up to date: correct, maybe we need to add this to a separate section on that page? Otherwise it might become confusing to newcomers?

[mstovenour]

I think we have a complete release process now so I'm closing this issue. After we run this process a few times to make sure it covers all our needs, it might be good to think about automation; but I'd rather make release automation a new issue to track.

Now when we think we have all the docs updated "enough" we can make the 3.1 release.