Look up the current version number. It will be on the format vX.Y.
If the next release is a major update, decide on the new version number by incrementing the X value with 1 and set the Y value to 0.
If the new release is a small update, decide on the new version number by keeping X as is, and incrementing the Y value with 1.
If needed the values can be made double digits and be on format vXX.YY.
[x] 2. Copy this checklist to an issue
On this page, click the Raw button and copy all the content of this page into an issue. Call this issue "Release checklist for vX.Y". Replace "X.Y" with the version number of the current release. Use this issue to keep track of the progress for this release.
[x] 3. Manage milestones
Edit the name of milestone called next-release. Name it vX.Y. Replace "X.Y" with the version number of the current release.
Create a new milestone and give that milestone the name next-release
[x] 4. Merge milestone to develop
Make sure that all fixed issues added to the milestone now called vX.Y are merged to the develop branch
For any issues not yet fixed, decide to either:
Fix it before continuing with this release
Move that issue to the next-release milestone
[x] 5. Create version branch vX.Y
This branch MUST be created from the main branch. Name this branch vX.Y where you replace "X.Y" with the version number of the current release.
[x] 6. Merge develop to the version branch
Solve all the conflicts in the vX.Y branch and then make sure that the sub-steps in this step are done in the vX.Y branch and nowhere else.
[x] 6.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] 6.2 Update version and date - In the vX.Y branch, update the version number and date in all ado-files and all dates in all help files. See section below for details.
[x] 6.3 Update version locals in ietoolkit - In the ietoolkit.ado file in the vX.Y branch, update the version and versionDate locals at the top of the file.
[x] 6.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] 7 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] 8. Email Prof. Baum
[x] 8.1 - If any commands are added or deleted, make note of that in the email.
[x] 8.2 - If any of the meta info (title, description, keywords, version or author/contact) has changed then include those updates in your email.
Email the .zip file created in the previous step to kit.baum@bc.edu.
[x] 9. 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] 10. 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] 11. Merge vX.Y branch to main
If step 2 and 3 was done correctly, then there should not be any merge conflicts in this step. Once merged, delete the vX.Y branch.
[x] 12. Close issues
When the new version is up, close all the issues that was solved in the new version.
[ ] 13. VERY IMPORTANT STEP - Update develop and feature branches
[ ] 13.1 Update develop from main
This step brings edits done in the vX.Y branch and main branch during the release into the develop branch. This can either be done with a rebase (more advances, but cleaner history) or a merge (less advance, but messier history).
Rebase: Rebase the develop branch onto main. The effect is that it looks as if the develop branch was created from where main is now.
Merge: Merge main into develop. The state of develop will be the same as after a rebase, but there will be merge arrows going multiple directions in the network graph. This is not too bad if done only with the develop branch, but looks messy if also done with feature branches in next step.
[ ] 13.2 Update feature branches from develop
Repeat the same process on all branches that are still open. But update the feature branches from develop and not main. Often it does not matter if you use main, but do it from develop in case more edits were already done in main.
[x] 14. Publish release note
Once the new version is up on SSC, publish the release note.
[x] 15. 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 X.Y 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 ietoolkit
program ietoolkit
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:ietoolkit}
{hline}
Checklist for v7.3
[x] 1. Decide on new version number
vX.Y.Xvalue with 1 and set theYvalue to 0.Xas is, and incrementing theYvalue with 1.vXX.YY.[x] 2. Copy this checklist to an issue
Rawbutton and copy all the content of this page into an issue. Call this issue "Release checklist for vX.Y". Replace "X.Y" with the version number of the current release. Use this issue to keep track of the progress for this release.[x] 3. Manage milestones
next-release. Name itvX.Y. Replace "X.Y" with the version number of the current release.next-release[x] 4. Merge milestone to
developvX.Yare merged to thedevelopbranchnext-releasemilestone[x] 5. Create version branch
vX.Ymainbranch. Name this branchvX.Ywhere you replace "X.Y" with the version number of the current release.[x] 6. Merge
developto the version branchvX.Ybranch and then make sure that the sub-steps in this step are done in thevX.Ybranch and nowhere else.developbranch, merge those todevelopand then re-mergedevelopto the version branch and test again.vX.Ybranch, update the version number and date in all ado-files and all dates in all help files. See section below for details.vX.Ybranch, update the version and versionDate locals at the top of the file.net install. If any new command has been added, remember to add the files for that command to the.pkgfile.[x] 7 Create a .zip file
[x] 8. Email Prof. Baum
[x] 9. Draft release note
[x] 10. Wait for publication confirmation
[x] 11. Merge
vX.Ybranch tomainvX.Ybranch.[x] 12. Close issues
[ ] 13. VERY IMPORTANT STEP - Update
developand feature branchesdevelopfrommainvX.Ybranch andmainbranch during the release into thedevelopbranch. This can either be done with a rebase (more advances, but cleaner history) or a merge (less advance, but messier history).developbranch ontomain. The effect is that it looks as if thedevelopbranch was created from wheremainis now.mainintodevelop. The state ofdevelopwill be the same as after a rebase, but there will be merge arrows going multiple directions in the network graph. This is not too bad if done only with thedevelopbranch, but looks messy if also done with feature branches in next step.developdevelopand notmain. Often it does not matter if you usemain, but do it fromdevelopin case more edits were already done inmain.[x] 14. Publish release note
[x] 15. 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
X.Ywhere 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.
Date at the top of the help file. Change only the date, there is no version number in the help file.