[x] 1. Merge to develop - Merge all branches with the changes that should be included in the new version first to the develop branch.
[x] 2. Create version branch - This branch MUST be created from the master branch. Name this branch the same as the version number you are about to release. For example, v1.1, v2.32 etc.
[x] 3. Merge develop to the version branch - Solve all the conflicts in the version branch and then make sure that step 3.1-3.4 are done in the version branch and nowhere else.
[x] 3.1 Test in different operative systems - This step is not necessary every time, but testing the commands in Stata on each of the PC, Mac and Linux operative systems should be done from time to time. A particularly good time to do this is after writing or editing code that depends on file paths, the console, special settings etc. If small updates are needed, then do them in the version branch, otherwise do them in branches of the develop branch, merge those to develop and then re-merge develop to the version branch and test again.
[x] 3.2 Update version and date - In the version branch, update the version number and date in all ado-files and all dates in all help files. See section below for details.
[x] 3.3 Update version locals in ietoolkit - In the ietoolkit.ado file in the version branch, update the version and versionDate locals at the top of the file.
[x] 3.4 Update version in .pkg and .toc - This has nothing to do with SSC but should be kept up to date to. This is for when people install directly through GitHub using net install. If any new command has been added, remember to add the files for that command to the .pkg file.
[x] 3.5 Create a .zip file - Create a .zip file with all ado-files and help files only. These files are not allowed to be in a sub-folder in this .zip file. No other files should be in this folder. Make a copy of this file in the archive folder of this package.
[x] 4. Email Prof. Baum - Email the .zip file created in step 3.5 to kit.baum@bc.edu.
[x] 4.1 - If any commands are added or deleted, make note of that in the email.
[x] 4.2 - If any of the meta info (title, description, keywords, version or author/contact) has changed then include those updates in your email.
[x] 5. Draft release note - Go to the release notes and draft a new release note for the new version. Follow the format from previous releases with links to issues solved.
[x] 6. Wait for publication confirmation - Do not proceed pass this step until Prof. Baum has confirmed that the new version is uploaded to the servers.
[x] 7. Merge version branch to master - If step 2 and 3 was done correctly, then there should not be any merge conflicts in this step. Once merged, delete the version branch.
[x] 8. Rebase develop to master - This step brings edits done in 3 and 3.1, as well as version updates done in 3.2 and 3.3 into the develop branch. The same result can be accomplished - although by creating a slightly messier history - by merging master into develop. Regardless if the branches are merged or rebased, if any branches created of develop was not included in this version, make sure to rebase them to develop afterwards, otherwise there is a big risk for very messy conflicts in the future.
[x] 9. Publish release note - Once the new version is up on SSC, publish the release note.
[x] 10. Close issues - When the new version is up, close all the issues that was solved in the new version.
[x] 11. Send announce email - If it is a major release (new commands or significant updates to existing commands), send an email to DIME Team to announce the new version.
developbranch.masterbranch. Name this branch the same as the version number you are about to release. For example,v1.1,v2.32etc.developbranch, merge those todevelopand then re-mergedevelopto the version branch and test again.net install. If any new command has been added, remember to add the files for that command to the.pkgfile.versionbranch.