Checklist for releast of version 1.5

[luizaandrade]

• [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 iefieldkit - In the iefieldkit.ado file, 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
  • [x] 3.5 Create a .zip file - Create a .zip file with all ado-files and help files in the folder you just created in the archive folder. Then remove all files but the .zip file from the archive folder.
• [x] 4. Email Prof. Baum - Email the .zip file created in step 3.4 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 authour/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.
• [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.
• [ ] 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.

Version number and dates in ado-files and help files.

The version number is on the format number.number where the first number is incremented if it is a major release. If the first number is incremented the second number is reset to 0. If it is not a major release, then the first number is left unchanged and the second number is incremented.

Version number and date in ado-file. Change both version number and date. Make sure that this line is the very first line in the ado-file:

*! version 5.4 15DEC2017  DIME Analytics dimeanalytics@worldbank.org

    capture program drop iefieldkit
    program iefieldkit

Date at the top of the help file. Change only the date, there is no version number in the help file.

{smcl}
{* 15 Dec 2017}{...}
{hline}
help for {hi:iefieldkit}
{hline}

[luizaandrade]

All done!

[kbjarkefur]

I want to add "re-base existing branches and write in check-list issue which branches were successfully re-based and which were not".

Re-base after v1.5:

• Sucessess:
  • iefieldkiterror
• Failures:
  • dev-iecorrect
  • iecodebook-hashdata
  • issue-100

Branches that fails to re-base starts to be so out of data that they might be gnarly to merge towards master.

[kbjarkefur]

No action required on the failed re-bases, but if I saw a branch that was mine that could be deleted in failures, then now would be a good time to do that. And if I saw one that I intend to work on, then I would try to solve this before it gets worse @bbdaniels and @luizaandrade

[luizaandrade]

I think that makes sense. I also added an item to update the command from SSC and make sure it's the last version once we get the email from Kit Baum

[luizaandrade]

I think we can close the branch on #100, since we decided not to implement it.

[kbjarkefur]

ok, I saw you deleted it now. thanks!